Portable Data Encryption Device with Configurable Security Functionality and Method for File Encryption

ABSTRACT

A portable encryption device with logon access controlled by an encryption key, with an on board cryptographic processor for reconstituting the encryption key from a plurality of secrets generated by a secret sharing algorithm, optionally shrouded with external secrets using an invertible transform resistant to quantum computing attacks. Another embodiment provides file decryption controlled by a file encryption key, with the on board cryptographic processor reconstituting the file encryption key from a version of the file encryption key which has been shrouded with a network authorization code. A method for encryption of a plaintext file by hashing, compressing, and encrypting the plaintext file, hashing the ciphertext, hashing the plaintext hash and the ciphertext hash, and sealing the ciphertext together with the resulting hash. A portable encryption device for performing the method is also disclosed.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional PatentApplication No. 60/886,087 titled “Modular Portable Storage Device AndSystem With Configurable Security Functionality” filed Jan. 22, 2007,the contents of which is incorporated by reference in this disclosure.

BACKGROUND OF THE INVENTION

The creation of proprietary digital information is arguably the mostvaluable intellectual asset developed, shared, and traded amongindividuals, businesses, institutions, and countries today. Thisinformation is mostly defined in electronic digital formats, e.g.,alphanumeric, audio, video, photographic, scanned image, etc. Theexposed storage and transport of this proprietary information,particularly for the purposes of sharing among separate collaborationgroups, has significantly increased the risk of interception and theftby criminal elements, competitors, amateur thieves, computer hackers,terrorists, or political or industrial spies.

Simultaneously, there is an increased need for mobility of such data byphysical or logical transport between home and office, or from office tooffice(s) among designated recipients. The dramatic increase in thevelocity of business transactions and the fusion of business, home, andtravel environments has accelerated sharing of this proprietarycommercial, government, and military digital information. To facilitatesharing and mobility, large amounts of valuable information may bestored on a variety of portable storage devices (e.g., memory cards,memory sticks, flash drives, optical and hard disc magnetic media) andmoved among home and office PCs, portable laptops, PDAs and cell phones,and data and video players and recorders. The physical mobility of thesestorage devices makes them vulnerable to theft, capture, loss, andpossible misuse. Indeed, the storage capacity of such portable storagedevices is now approaching a terabyte, sufficient to capture an entirecomputer operating environment and associated data. This would permitcopying a targeted computer on the storage media and replicating theentire data environment on an unauthorized “virgin” computer or hostdevice.

Another trend in data mobility is to upload and download data on demandover a network, so that the most recent version of the data is alwaysaccessible and can be shared only with authorized users. Thisfacilitates the use of “thin client” software and minimizes the cost ofstoring replicated versions of the data, facilitates the implementationof a common backup and long-term storage retention and/or purging plan,and may provide enhanced visibility and auditing as to who accessed thedata and the time of access, as may be required for regulatorycompliance. However, thin client software greatly increases thevulnerability of such data to hackers who are able to penetrate thefirewalls and other mechanisms, unless the data is encrypted on thestorage medium in such a way that only authorized users could make senseof it, even if an unauthorized user were able to access the encryptedfiles.

There is a balance among legal, economic, national security, andpragmatic motivations to develop robust security implementations andpolicies to protect the storage of proprietary digital information,based on the value of the information, the consequences of its exposureor theft, and the identification and trust associated with each of thetargeted recipients. In order to provide such varying degrees ofprotection for portable storage devices, system methods and applicationfunctionality must be developed and easily integrated into the operatingprocedures of the relevant institutions. Different policies definingdegrees of protection are required to economically accommodate and adaptto a wide range of targeted recipient audiences for this data.

Currently and predominantly, for portable storage devices, passwords andsoftware solutions are used for such purposes as encryption ofinformation and to provide the authentication functions to access andmanipulate private intellectual property. The sophistication ofliterally millions of mathematicians, computer engineers and scientists,many of whom can be hostile to the protection of digital intellectualproperty for economic, political, or frivolous purposes, represents agreat threat to the efficacy of simple implementations of passwordsecurity and software encryption systems currently implemented on suchportable encryption devices. Furthermore, the difficulty and, in somecases, the inability to change security policies for access to such dataforms yet another barrier to the commercial and institutional interestsof the owners of the intellectual property in controlled and directedsharing of such information, and of the user's ability to retrieve,search, and store such data in their daily activities.

In contrast, some users have adopted the use of hardware-basedencryption solutions in order to prevent these problems, only todiscover a few years later that their data was irretrievable becausetheir cryptographic token was lost, stolen, or malfunctioned and theyhad no backup or recovery agent capability, or that interesting or evenvital historical records could not be read because no information existsas to what keys were used to encrypt the documents, or what tokens orPINs were used. It is easy to imagine that if these issues are asignificant problem today, then the problem of encrypting data forpersonal privacy for 40 or 50 years, or even the life of the individual,will become overwhelming.

What is needed are highly robust and proven security techniquesincorporated into new system methods and into new commercially availableportable storage hardware apparatus to implement configurable securitypolicies for accessing information through rigorous authenticationmeans, to secure the information with certified levels of acceptedcryptographic technology, and to rigorously control the environmentwithin which the information is shared. What is needed is a secureportable storage apparatus and method of encrypting and sealing (via acombination of secure hash and digital signature technologies) digitalinformation files and storing them in the device's integral or removablememory, or alternatively on the host device's memory or other ancillarymemory storage devices, while operating under cryptographicallyprotected security policies for transport and authorized access to suchdigital information.

It is essential that the portable encryption device provide and make useof a highly secure logon mechanism, to ensure that a user is not allowedto or even be capable of operating the device in order to encrypt,decrypt, sign, or verify the data, or perform various other sensitiveoperations unless and until that user has been specificallyauthenticated and authorized in accordance with the organization'ssecurity policies and procedures. To this end, it would be verydesirable for the device to support the use of a secure PIN entrymechanism, as well as supporting an optional biometric identificationmechanism, and various other optional enhanced authentication devices,functions, and methods.

Because the secure portable encryption device may be used in a highthreat and high-risk environment, there is the possibility that thedevice could be lost, stolen, or captured by competitive or criminalforces, and later disassembled and even reverse engineered by asophisticated and capable adversary. For this reason, it is highlydesirable that it be impossible for such an organization to extract theuser's authorization PIN or password, biometric template, or otherenhanced authentication/authorization parameters, or any of the privatekeys or critical cryptographic parameters, either from the data itself,the encryption device itself, or from the cryptographic processor, orfrom combination of the three.

There is a need for secure physical and logical transport of data formultiple recipients. To this end, it is desirable to provide a means ofsecurely transporting data from one place to another, if the user has tocarry the data with him or her, or physically transport the data and thesecure encryption device, and somehow communicate the informationnecessary to log on and access the data by another authorized user. Whatis required are a multiplicity of methods to securely transport theencrypted data, either physically or logically, between an Originatoruser and one or more authorized Recipient users of devices and hostcomputers that are operating within authorized enclaves or domains, orare members of certain authorized Communities of Interest.

An “enclave” is considered to consist of one or more host computersoperating within a single organization or enterprise and under thecontrol of a common security administration, typically subject to somelevel of physical security, and within which there is some reasonableexpectation of interoperability with respect to the use of the subjectinvention. An example of an enclave would be the computers used within asingle corporate campus, such that an employee could insert and use thesecure portable secure encryption device. An enclave may be restrictedin its scope to include only those host computers that are authorized toprocess information of a particular type, e.g., Engineering, HumanResources, or Finance. A given host computer may be authorized to be amember of multiple enclaves. A “domain” is considered to consist of oneor more enclaves distributed across one or more enterprises ororganizations, all operating within a common security framework andpolicy. An example would be a collection of computers operating at theSECRET level throughout a portion of the Department of Defense,including civilian contractors and other cleared users. A “Community ofInterest” is typically a more loosely defined set of host processors andusers who all share a common interest and “Need to Know,” even if (insome cases) that interest spans enclaves and domains and evengovernmental boundaries. An example would be communications between theU.S. military and our allied and coalition partners, and in some caseseven indigenous tribal authorities and informal collaborators. In thecivilian or social networking sphere, a community of interest mightinclude “Friends and Family,” a chat room, membership on a professionalor social e-mail or blog list, etc.

In many environments, it is not sufficient merely to restrict thephysical access and ability to log on to the device to certain hostcomputers within a given enclave. Instead, there is a need forrestricted communication and data containment, and it is necessary toconstrain encrypted communications to those members of a pre-definedCommunity of Interest, so that no one outside of that Community ofInterest could possibly decrypt the message. Such a mechanism could beused to enforce Mandatory Access Controls (e.g., clearance levels,compartments, and/or caveats in the military), or a defined Need-To-Knowfor various proprietary or sensitive types of information in commercialenterprises.

It is very important to provide a mechanism for data confinement, suchthat the secure portable encryption device can only be used incombination with an authorized host-computing device. In a militaryenvironment, such a mechanism would prevent the encrypted data frombeing compromised even if the user were coerced into divulging orentering the PIN or password and activating any biometric sensors. In acommercial enterprise environment, such a mechanism could be used toprevent an authorized user from accessing and storing proprietary orpersonal of data and later decrypting them on his home computer withoutproper authorization, for personal gain, vicarious pleasure, or purposesthat are more nefarious.

Similarly, in multiple-recipient data sharing modes of operation, itwould be highly desirable to provide one or more system methods or meansto control access and cryptographic operations, so that the datacontained in or secured by such a secure portable encryption device canonly be encrypted on behalf of, and decrypted by, an authorized user,and only on an authorized host computing device as dictated by thesecurity policies of the enclave, domain, or Community of Interest; andnot by just anyone who may possess an encryption key pair that could beused in the encryption/decryption process. It would also be highlydesirable to ensure that the data is authenticated as having originatedby a given user, and to provide nonrepudiation-level protection againstmanipulation or substitution of the data by an attacker.

It would also be highly desirable if a “blocking” or “guard processor”can be provided to ensure that only encrypted and sealed information canbe written to or read from designated input/output ports or devices,including removable media. Similarly, it would be highly desirable tosupport the use of a “black” guard processor that could examine anyincoming or outgoing traffic on a communications link to ensure that itwas properly encrypted and had not been modified prior to allowing it tobe transmitted or received, without the necessity of providing the guardprocessor the ability to decrypt the data. A “red” guard processor couldalso be used to decrypt and examine the data for specified sensitivecontext prior to either releasing it for transmission or, if sensitivedata is identified, returning it to the originator with instructions todelete the sensitive data, and perhaps raising an alarm or log eventthat proper policies have not been followed.

There is a need for very long term data recovery mechanisms, and inorder to conform to various regulatory and organizational governancerequirements, it is desirable that one or more recovery agents besupported, possibly of different types, so that the encrypted data canbe decrypted if necessary, even if the original cryptographic keys havebeen lost and the original user's PIN forgotten. Preferably, thenecessary information to support this recovery must be embedded in theencrypted data itself.

In the case of small businesses or home users, it may be important toprovide some form of an inexpensive Recovery Agent capability that canbe used in conjunction with a primary encryption device to decrypt andrecover data on a one-time-only basis. Because such a device or meanswill only be used in the event of the loss or malfunction of the primarydevice, it may be sufficient (and desirable from a marketingperspective) if the functionality can be limited to a decrypt-only modeof operation. For this reason, it is desirable to support a hybrid modeof operation, providing a static private Elliptic Curve Cryptography(“ECC”) key within a security processor or token, to be used fordecryption only; with the symmetric key encryption being performed insoftware, or at a very bandwidth-limited rate in hardware.

Because it is difficult to predict the course of history, thepossibility of natural disasters, the failure or obsolescence of thehardware device, and even the dissolution of the original equipmentvendor or the user's organization, it is desirable that a highly robustsolution be devised to enable distant generations to read the dataeasily, while at the same time protecting the data as securely aspossible for the current generation. This requires what we define as“strong but brittle cryptography”—a cryptographic system that willresist all known attacks for a well-defined period of years or decades,and then will suddenly “snap” and provide relatively simple access tothe data by future historians. Because it is difficult to ensure thatany hardware mechanism will survive for many decades without failure, inaddition to the hybrid decryption function described previously, it isdesirable to support a decrypt-only function in a purely software meansor mechanism, so that the inevitable changes in computers, operatingsystems, applications, and even programming languages can beaccommodated by updating or porting the software functionality to thefuture environment.

Finally, it must be recognized that the long-term storage of encrypteddata presents some very difficult problems in sorting, searching, oreven finding any data that is relevant to a particular subject, withoutbeing forced to decrypt the entire archive in order to find something.This process is difficult enough if the document is a text document thatcan be searched relatively easily, but if the information that is soughtis a photograph, drawing, sound recording, musical score, computerprogram, or other more abstract data type, then the search process canbe very difficult indeed. In addition to the search difficulty, there isa cost associated with the long-term storage of any kind of data,encrypted or not, and it is often necessary to make an intelligentdecision as to what to save and what to discard. But if the informationis encrypted, making that decision effectively requires that theinformation be decrypted in order to examine it, and that may not bepractical if terabytes, exabytes, or even petabytes of data areinvolved. For this reason, it would be desirable if metadata—data aboutthe data—could be saved along with the encrypted data itself. Thismetadata might or might not be as sensitive as the data itself, just asthe subject of an e-mail might or might not be particularly revealing.In some cases, it may not be necessary to encrypt the metadata at all,and in other cases, it may be sufficient to encrypt the metadata using akey that is common across many such files or messages, and is sharedwith a central archive, catalog, or directory facility. It is thereforedesirable to provide a mechanism for attaching metadata to the encryptedfile in such a manner as to facilitate the cataloging and subsequentdiscovery of the contents of the files involved, and allowing themetadata to be sent in the clear, or encrypted in a common key or keysof the archive facility or catalog.

In modern communications systems, data, typically in the form of a file,may be communicated, relayed, and stored over a large number ofcommunications and storage media, each of which has some small butfinite probability of introducing an error into the transmission orstorage of that information. Even if the error is later detected, it maynot be possible to correct it if the original source is no longeravailable. In particular, depending on the Mode of Operation of thecryptographic system, an uncorrected error may cause error propagationthroughout the remainder of the decrypted file or message after thepoint of the error, rendering the data completely unintelligible. Thisis a particular problem in the case of one-way transmissions, e.g., whenthe recipient is operating under “EMCON” (emissions control) or radiosilence conditions, as well as for one-way storage or archiveoperations. Although it may not possible to prevent such errorscompletely, it is desirable to have robust error detection andcorrection, and to make use of Forward Error Correction techniques thatare embedded in the file or message itself, and therefore can be used torecover errors on an end-to-end basis, rather than having to rely on theproper operation of every intermediate link and storage mechanism.

In implementing all of the above functionality, it is highly desirablethat the methods and apparatus use encryption/decryption and digitalsigning techniques and related private key and public key algorithms andkey sizes that are preferred by the communities of users or have beenadopted by international or national standards, or are proprietary tounique institutions. One preferred cryptographic embodiment andimplementation is currently (year 2008) represented by the “Suite B”algorithms for both unclassified and classified use by the U.S.Government. Suite B consists of Elliptic Curve Cryptography (ECC) in theprime field GF(P) using key sizes P-256 and P-384 for key establishmentbetween two parties as well as for digital signature creation andverification; the Advanced Encryption Standard (AES) with keys sizes of128 or 256 bits for symmetric key encryption; and the updated SecureHash Algorithms (SHA-256 and SHA-384).

At the present time, extrapolating the increase in performance and scaleof existing technology indicates that the ECC P-384 keys should resistattacks by even nation-states for well over 100 years. However, thelooming threat on the horizon is the possibility of highly parallelcomputations made possible by a form of computation called “quantumcomputing.” At present, many of the cryptographic protocols, includingRSA and ECC are believed to be secure, in that the effort which would berequired to break them is considered computationally infeasible. Thepossibility that quantum computing might become feasible would changethis picture dramatically. If realized, the difficulty of most of theseproblems would drop from exponential complexity to merely polynomialcomplexity, rendering currently deployed cryptographic systems and keylengths useless. Current expectations by knowledgeable people in thefield are that quantum-computing attacks against ECC might becomefeasible within 30 to 50 years, and that we may have a betterunderstanding of the threat within 10 years. At least at present, theredoes not seem to be a comparable threat against AES, particular AES-256.The possible threat against “SHA-2” is not known, but NIST has initiateda call for a next generation of hashing functions, “SHA-3.” It istherefore desirable to resist quantum-computing attacks against ECC andagainst SHA-2 wherever possible.

Most prior art solutions to secure information on portable storagedevices for transport to different host computing devices or for use byauthorized users have certain vulnerabilities as a result of theirreliance on software and unprotected hardware implementations, or on thelong term, static, non-volatile, and accessible storage of importantcodes and cryptographic parameters. These vulnerabilities have becomemuch more widely exploitable due to the readily available technologicaland intellectual resources possessed by well-funded criminal elements,rogue nations, terrorists, and political and military enemies. As ofDecember 2006, as quoted in the New York Times, “Despite an almostfour-and-half-year campaign on the part of the company (Microsoft), andthe best interests of the computer industry, the threat from harmfulcomputer software continues to grow. Criminal attacks now range fromprograms that steal information from home and corporate PCs to growingarmies of slave computers that are wreaking havoc on the commercialInternet.” Many computer security companies say that there is a livelyunderground market for information that permits attackers to break intosystems via the Internet through Trojan horses among other hardware andsoftware means of invasion of processors and software.

Attacks on personal computers and commercial, government and militarydata are now commonplace; indeed, identity theft of passwords is thelargest white-collar crime in the United States. Yet passwords and PINs(Personal Identification Numbers), in most cases generated by humanbeings who are tempted to use native-language words, Social SecurityNumbers, telephone numbers, etc., are still the most used accesssecurity methods for protecting portable encryption devices, and amongthe most vulnerable to both brute force dictionary attacks as well assophisticated logic tracing. Professional criminal attackers and evenamateur hackers now have access to sophisticated software andsupercomputing networks that can unknowingly invade processing devicesand storage devices, trace software instruction sequences and memorylocations, and by knowing or discovering the algorithms being used,intercept and copy encryption keys, PINs, and other profile data used toprotect the access to stored content. They can exploit vulnerabilitiesin the underlying commercial software, or in the construction of theintegrated circuit chips housing and executing the cryptographicprocesses, or in the specialized cryptographic software, which enablesexposing keys and access parameters at some deterministic point in theprocessing sequence. Industrial laboratory facilities are also availableto read the data content stored in memory cells by measuring theelectronic charge through the use of electronic beam microscopes, andthus steal stored PINs, keys, and therefore access the previouslyprotected data.

One of the key deficiencies of prior art, therefore, is the widespreadreliance on a stored PIN or password that is used for comparisonpurpose, for access control, or used for password-based encryption toprotect other cryptographic variables. Typically, the value that isstored is not the PIN itself, but a hashed or otherwise obfuscatedversion of the PIN, e.g., in the form produced by a PKCS#5 process. Inthe case of a password-based encryption process, the PIN itself may notbe stored, but only the encrypted key, which may then be used to encryptother information. In any case, however, some kind of a value is stored,and if it is possible to locate and extract that value, then in generalit is then possible to mount an offline exhaustive search attack againstthe PIN itself, with no constraints as to the amount of time, number ofunsuccessful attempts, or the number of networked distributed processorsthat may be applied to such an effort. Many of the more celebratedattacks against Digital Rights Management and copy protection systemsfor digital media, for example, have been successfully carried out bysuch means.

Prior art is also directed at methods of cataloging user access atdifferent security sensitivity levels and in different communities ofinterest through implementation of access control tables generallylocated at centralized servers. These tables are controlled by aninstitution's centralized policies that specify predetermined accessrights for each of a plurality of users relative to data resources whichthemselves are identified with predetermined levels of security. Accesstables further include domain and rule information for each user tocontrol the collection of domains and conditions of authorization oftheir security rights. Such systems are optimized for protecting accessto centralized sensitive data but are not adaptable to secure the userauthorization and access and decryption rights to data which istransportable via portable storage media. Since the table data isexternal to the secured media on which the data is stored, the processesto authenticate the user and authorize decryption of the data aregenerally not cryptographically secure nor are they adaptable to beimplemented by the portable storage device itself, even with thepresence of processing capability on the device.

Many prior art methods exist for the key management protection necessaryfor securing key encryption keys for large groups of users. Split-keysecret sharing schemes have been proposed whereby the decryption key issplit and shared among multiple parties or entities to be combined toreconstitute the decryption key. In these cases, however, the individualsecret shares themselves are maintained statically in multiple storagedevices, generally on-line, where they are susceptible to attackers,particularly from within the institution, who can target the secretshares and recombine then to form the decryption key. Such solutions areimplemented for relatively static configurations of computing andstorage devices and related communities of interest or tiers of users,and have not addressed the ability to so protect key encrypting keyswhen the data itself, and the means to encrypt and decrypt the data andto generate and recombine the shared secrets, are on a portable device.

SUMMARY OF THE INVENTION

The present invention addresses these issues and severely mitigates oreliminates vulnerabilities or requires levels of time and effort thatcould well render the value of the information as insignificant by thetime it could be exposed as plaintext. Through the use of the methods,apparatus, and system represented by the invention, together with theselection of available manufacturing techniques for protection ofcircuit chip contents by means of physically bonded sealing andshielding, self-destructive anti-tampering logic to zeroize memorycontents, and advanced techniques for mitigating so-called side-channelattacks, a commercially affordable and superior security solution forprotecting the access to portable stored data by unauthorized hostcomputing devices or unauthorized users can be introduced to the public.

A portable encryption device with logon access controlled by anencryption key is disclosed comprising an enclosure for the deviceproviding a portable form factor, and a cryptographic processor withinthe enclosure for reconstituting the encryption key from a plurality ofsecrets generated by a secret sharing algorithm. The secret sharingalgorithm may comprise a K out of N secret sharing mechanism, such asShamir's Secret-Sharing Algorithm with Lagrange interpolation. Theencryption key may be, for example, a master key encryption key, orapplication key encryption key.

Optionally, one or more of the generated secrets have been shrouded withone or more external secrets using an invertible transform, such thatany one of the external secrets may be changed without recreation orre-dealing of all of the plurality of generated secrets. A suitableinvertible transform is XOR. One or more of the external secrets maycomprise a user's PIN, which may be a supervisory user's PIN. Stillfurther embodiments are possible where the external secrets comprise aplurality of user's PINs, and the transform is invertible with less thanall of the plurality of user's PINs.

Other embodiments of the external secrets are possible, such as whereone or more of the external secrets comprise a firmware hash, one ormore of the external secrets comprise a host authorization codeassociated with one or more specific host computing devices, binding theportable encryption device to such one or more host computing devices,or one or more of the external secrets is generated by a proximitydetection mechanism. An external secret can also be a function ofmultivariate parameters, such as geographic-locus or biometric input.Optionally, the external secrets are communicated over a secure channelwith a secondary device, such as a connected host computing device, or aremote device.

Means for interfacing with a user authentication device can be added,such as a secure PIN entry mechanism, or secure biometric input. Stillfurther embodiments comprise removable memory configured for datastorage, a data communication module, or additional cryptographicprocessors within the enclosure. The cryptographic processor may be amicroprocessor that has been programmed to execute cryptographicfunctions.

A method for controlling logon access on a portable encryption devicehaving a portable form factor and a cryptographic processor isdisclosed, comprising generating a plurality of secrets by a secretsharing algorithm, configuring the cryptographic processor toreconstitute an encryption key from the plurality of generated secrets,and determining logon access as a function of the reconstitutedencryption key. The secret sharing algorithm may comprise a K out of Nsecret sharing mechanism, such as Shamir's Secret-Sharing Algorithm withLagrange interpolation. The encryption key may be, for example, a masterkey encryption key, or application key encryption key.

Optionally, a further step can be added of shrouding one or more of thegenerated secrets with one or more external secrets using an invertibletransform, such that any one of the external secrets may be changedwithout recreation or re-dealing of all of the plurality of secrets. Asuitable invertible transform is XOR. One or more of the externalsecrets may comprise a user's PIN, which may be a supervisory user'sPIN. Still further embodiments are possible where the external secretscomprise a plurality of user's PINs, and the transform is invertiblewith less than all of the plurality of user's PINs.

Other embodiments of the external secrets are possible, as noted above.Optionally, a further step can be added of communicating the externalsecrets over a secure channel with a secondary device, such as aconnected host computing device, or a remote device. In a still furtherembodiment, a step is added of receiving input from a userauthentication device, such as secure biometric data, optionally over asecure channel.

A portable encryption device with file decryption controlled by a fileencryption key is disclosed comprising an enclosure for the deviceproviding a portable form factor, and a cryptographic processor withinthe enclosure for reconstituting the file encryption key from a versionof the file encryption key which has been shrouded with a networkauthorization code.

A method for controlling file decryption with a portable encryptiondevice having a portable form factor and a cryptographic processor isdisclosed, comprising generating a network authorization code,distributing the network authorization code to a community of interestthrough an out-of-band distribution mechanism, shrouding a fileencryption key with the network authorization code using an invertibletransform, receiving the network authorization code from a user, causingthe cryptographic processor to reconstitute the file encryption key fromthe received network authorization code, and determining file access asa function of the reconstituted file encryption key. An encrypted filemay then be decrypted as a function of the reconstituted file encryptionkey. The invertible transform may be XOR, or an invertible transformthat is resistant to quantum computing attacks. In a further step, thenetwork authorization code is encrypted and code is distributed to arecovery agent.

A method for file encryption of a plaintext file is disclosed,comprising the steps of hashing the plaintext file to produce aplaintext hash, compressing the plaintext file, encrypting thecompressed plaintext file to create ciphertext, hashing the ciphertextto produce a ciphertext hash, hashing the plaintext hash and theciphertext hash to produce a result hash, and sealing the ciphertexttogether with the result hash using a digital signature algorithm toproduce the encrypted file. The encrypted file may be communicated tooriginator-selected optional recipients. A portable encryption devicehaving a portable form factor and an on-board cryptographic processormay be used to perform the method.

Further optional embodiments provide for an enforced mandatory recoveryagent, breaking the encryption of the encrypted file at a pre-determineddate, or embedding forward error correction within the encrypted file.

Where the plaintext file has metadata, a further embodiment separatelyencrypts the metadata, and the seals the ciphertext together with theresult hash and the encrypted metadata. Optional further steps forindependent key exchange mechanism to permit decrypting the metadata bycatalog agent are possible.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one embodiment of how a SPED can beutilized.

FIG. 2A is a block diagram of a HCD, and one embodiment of an SPED, andbiometric authenticator configurations.

FIG. 2B is a perspective view of one embodiment of an HCD and SPED.

FIG. 2C is a sketch of an SPED in a portable form factor.

FIG. 3A is a block diagram of the SPED with optional removable memorymodule and an optional user authentication device comprising a securePIN entry mechanism and biometric input.

FIG. 3B is a view of a physical implementation of one embodiment of asystem incorporating an SPED and HCD.

FIG. 4 is a flow chart of a method, according to an embodiment, forinstalling software to initiate use of an SPED and to authenticate auser or system security officer.

FIG. 5 is a block diagram of an HCD, according to one embodiment of theinvention.

FIG. 6 is a block diagram illustrating one embodiment of the HCD, theSPED, and the optional secure PIN entry/biometric sensor device.

FIG. 7 is a flow chart of a method, according to one embodiment of theinvention, for selecting among the different modes of operation of asystem according to one embodiment of the invention.

FIG. 8 is a flow chart of one embodiment of key management within anSPED.

FIG. 9 is a block diagram of another embodiment of the physicalimplementation of the system with security operations executed bysoftware within the SPED.

DETAILED DESCRIPTION

In accordance with the present invention, cryptographic operations areimplemented on data for secure storage and transport by means of asystem comprised of one or more than one secure portable encryptiondevice (“SPED”) capable of such cryptographic operations, and optionallystoring and communicating such secure data to host or peripheraldevices, one or more than one host computing device (“HCD”), and meansfor securely protecting access to that data. One embodiment of the meansfor securely protecting data is to permit access and cryptographicoperations on that data only to authorized recipients, or only onauthorized host computing devices, by a “K of N” split-knowledge sharingalgorithm method of generating and cryptographically assigning shroudedsecret shares which are bound to authentication/authorization means suchas shareholder PINs, passwords, Host Authorization Codes (HAC), or otherhost, SPED, or other user authentication/authorization means as will beknown to one or ordinary skill in the art with reference to thisdisclosure. Another embodiment of the means for securely protecting datais to utilize a Network Access Code (“NAC”) as part of a shroudingoperation on file encryption keys. Another embodiment is a method forfile encryption of a plaintext file, comprising the steps of hashing theplaintext file to produce a plaintext hash, compressing the plaintextfile, encrypting the compressed plaintext file to create ciphertext,hashing the ciphertext to produce a ciphertext hash, hashing theplaintext hash and the ciphertext hash to produce a result hash, andsealing the ciphertext together with the result hash, to produce theencrypted file. These and other embodiments will now be discussed indetail. It should be noted that these embodiments could be used alone,or in combination.

As will be understood by those skilled in the art, the phrase“cryptographic operation” includes hashing, encryption/decryption,digital signature/verification, and sealing (e.g., hashed and digitallysigned ciphertext). The term “PIN” (Personal Identification Number) isused herein to designate a (typically short) series of numbers, analphanumeric password, or a lengthy passphrase consisting of arbitrarywords, letters, numbers, and/or special characters without limitation.

In one embodiment, the SPED is used to communicate with the HCD toenable one or more cryptographic operations to be performed by the SPEDon data provided from the HCD to the SPED (which data can then be, forexample, stored in the SPED or returned to the HCD for storage) or ondata that has been transmitted by wire or wireless means to the SPEDfrom another device, or input to the SPED by a person.

In another embodiment, the data may be represented and stored asindividually encrypted and/or sealed files. In general, the process ofhashing, compressing, encrypting, and digitally sealing the file resultsin a new object that may be of considerably different size, eitherlarger or more often smaller than the original, with the result that theencrypted file cannot simply replace the original file. As a result, theact of storing the encrypted file must involve interactions with thedirectory or File Allocation Table in ways that the originating programor operating system cannot easily discern. For this reason, the means ofencrypting these files may either be a straight pass-through, generallyrequiring the implementation of a file-handling system within the SPEDitself, or the data may be looped-back to the HCD, either for storagelocally, or for yet another pass, wherein the files are broken up intodiscrete sectors by the host operating system prior to being stored onthe SPED, such that the SPED is not required to implement the requiredfile processing logic.

Split-Knowledge Sharing Algorithm Method of Generating andCryptographically Assigning Shrouded Secret Shares which are Bound toAuthentication/Authorization Means

In one embodiment, the means of generating and distributing HostAuthorization Codes for host computing devices on the basis of securitypolicies allows an institution to permit users to securely move databack and forth among a multiplicity of computers in a defined enclave,for example, between a branch and a central office, but prevents a userfrom decrypting the data on an unauthorized machine, even if the userpossesses the encrypted data, the SPED device containing the keysnecessary to decrypt the data, and is in possession of the PIN/passwordrequired for access, and can even satisfy any biometric criteria, solong as he does not know the Host Authorization Code, or other EnhancedAuthorization codes, devices, or methods. This invention dynamicallydefines and configures the authorized population and tiers of users,portable encryption devices, and host computing devices.

As will be described, the use of a set of K out of N shrouded secrets toreconstitute a Master Key Encryption Key involves the use of anexclusive-OR operation for the shrouding, and a mathematical algorithm(Shamir's secret sharing algorithm) involving N equations with Kunknowns. Neither of those operations involve the use of cryptography inthe conventional sense, and the difficulty of “breaking” such schemesdoes not depend upon any assumptions of computational intractability,but instead provide provable mathematical intractability. With respectto the K out of N secret sharing scheme, for example, if fewer than Kshares are entered, or if any of the shares are entered incorrectly,then the results are mathematically indeterminate and no better thanrandom guessing. Likewise, if even a single bit is in error in theshrouded calculation, then the result is simply incorrect, and providesabsolutely no information that might aid an attacker.

For this reason, this embodiment of the invention providesmathematically provable security with regard to the reconstitution ofthe Master Key Encryption Key. Even if a very sophisticated laboratoryattack could be used to “peel” the security processor chip and extractthe contents, without the knowledge of K out of N of the authenticationfactors, it is mathematically impossible to recover any data, unlesssomeone can break the AES-256 key wrapping algorithm.

Two Subsystems for Distributing Secret Shares and Host AuthorizationCodes

In one embodiment, two subsystems operate in conjunction for creatingand distributing secret shares and Host Authorization Codes according tothe authorized configuration of users, secure portable encryptiondevices, and host computing devices: (1) a hardware-based encryptiondevice identified as the Secure Portable Encryption Device (SPED) thatconnects to a host computer device via an interface such as a UniversalSerial Bus (USB 2.0 or 1.1), an ExpressCard™ interface, or other similarwired or wireless functionality, and contains its own integratedcryptographic security and operational processing capabilities andmemory storage facilities, and (2) a general purpose computer, or a formof PC computer, PDA, cell phone, or other type of programmable computingdevice supporting applications software, referred to as the hostcomputer device, which contains a suitable operating system, thenecessary device drivers and other middleware, and an applicationprogram which provides the Graphical User Interface (GUI) to control thefunctionality.

Overview of the Major Functional Parts of the System

Referring to FIG. 1 of the drawings, the Originator/user 11 of data 12is shown as part of the block diagram which depicts the various majorfunctional parts of the system including the two apparatus subsystems,the secure portable encryption device 14 (hereinafter referred to as theSPED) and the host computing device 13 (hereinafter referred to as theHCD). It also illustrates the cryptographic system means 20 by whichaccess to the stored content of the SPED 14 is authorized only fordesignated users 11 and HCDs 13. Data 12 is introduced into the systemfor the purpose of having some cryptographic operations performed on it(e.g., digital signature, hashing, encryption) in order that it may besecured in the HCD 13 to be securely transported 15, via the SPED 14, toanother authorized HCD 13 for the originator's 11 use, or for use onlyby an authorized Recipient 17, and protecting the SPED 14 so that, iflost, the data content cannot be accessed.

The data 12 can be any form of digital data (text, photographic,scanned, audio, video, etc.) and can be generated through keyboard input18 by the user 11, or input by the user through attachment of aperipheral device (e.g., disc reader, memory storage device, digitalcamera, etc.) or downloaded through some form of wired or wirelessnetwork connection to either the HCD 13 or the SPED 14.

The SPED 14 can be of a form such as a flash drive token, or a digitalmedia recorder/receiver or iPod® type device, with integral orreplaceable/removable memory, comprised of cryptographic and operationalprocessing hardware capabilities, control and flow logic controls, andinterface connections for multiple device attachments.

The SPED 14 is connected to an HCD 13 such as a personal computer,hereinafter referred to as a PC. Other forms of HCDs 13 may be cellphones, video recorders, workstations, or other device configurationswhich support an input device 18 for input of user commands (e.g., akeyboard or touch screen), some form of display 19 for graphicallyproviding information to the user, a form of digital computer processorfor computing on data and interfacing with the input commands suppliedby the user, storage memory means for storing data and programinstructions, connection port interfaces (e.g., USB, Firewire,ExpressCard™) for connecting with peripherals (e.g., disc storage,printers, scanners) and communications devices (e.g., WLAN, Ethernet,modems), control logic and busses for routing of data and controlsignals among all the elements of the device and with externalperipheral devices sufficient to perform the functions required by theapplication, and some form of operating system software (e.g., WindowsXP®, Windows Mobile®, VISTA®, MAC OS®, Linux®, Symbian®) which providesthe process control and sequencing of all instructions, operations, anddata flows within the HCD 13 and to all peripheral devices, and supportsapplications software which can be loaded through digital media (e.g.,CD-ROM) or downloaded via the internet or some other network facility.

Externally generated data may be loaded into the HCD via any of theavailable interfaces of the HCD or, in another embodiment, loaded intothe SPED through an external secondary connector integral to the SPED.

Description of Split-Knowledge and the Application of Shamir'sSecret-Sharing Algorithm

Access to the SPED 14 contents and its operation with an HCD 13 iscontrolled by authentication of an authorized user 11 and a HCD 13authorized by the SPED 14 through use of a split-knowledge approach thatapplies the Shamir secret sharing algorithm, which is well known tothose who practice the state-of-the-art in cryptography. System meansfor implementation of the secret sharing algorithm is comprised ofcomputing method 20, executed by cooperation between host computingdevice 13 and secure portable encryption device 14, that creates theMaster Key Encryption Key that protects the critical cryptographicparameters of the SPED and creates secret authorization shares whichprotect the contents of the SPED from access by any but authorized userson authorized HCDs. It should be understood that in the case of multiplecryptographic applications, a multiplicity of Application Key EncryptionKeys (AKEKs) may be used, with one AKEK being used per application,rather than a single Master Key Encryption Key for the entire device.The following detailed descriptions will apply to a single Master KeyEncryption Key or a multiple Application Key Encryption Key.

Secret Sharing

Secret sharing refers to any method for distributing a secret amongst agroup of entities, human or inanimate, each of which is allocated ashare of the secret. The secret can only be reconstructed when theshares are combined together; individual shares are of no use on theirown. Secret sharing schemes were discovered independently by Blakley andShamir. The motivation for secret sharing is secure key management.There is one secret key, the SPED 14 Master Key Encryption Key (theMKEK), (or potentially one or more Application Key Encryption Keys perapplication) which provides access to all the secure keys and criticalcryptographic attributes held by the SPED 14.

Secret shares are created within the SPED 14 through an initializationprocess that generates, according to the method of Shamir, a temporarypolynomial equation from which the MKEK and the secret shares arederived. The shares are then individually combined and shrouded, throughthe use of a transform, with external secrets (e.g., PINs, authorizationcodes) from each of the entities or components comprising the system(e.g., users and apparatus, namely, users 11, the HCDs 13, and the SPED14). The novelty of storing and using a transform rather than the secretshares themselves prevents collusion of external entities, which haveknowledge of their own external secrets, from recovering andreconstituting the MKEK or AKEKs, and allows simpler logistics forchanging any individual entity's secret without generating a newpolynomial and distributing new shares to all. The external secrets arerequired inputs for authorization to reconstitute the secret MKEK or anAKEK and access the secured data contents contained by the SPED 14 orthe associated HCD 13.

Any group of K or more entities (up to N) can come together toreconstruct the secret MKEK or an AKEK, but no group of less than Kentities can accomplish this. Such a system is called a (K,N)-thresholdscheme.

A popular technique to implement share reconstitution in polynomialbased threshold schemes uses polynomial interpolation (“Lagrangeinterpolation”). Two points uniquely define a line, three points definea parabola, four define a cubic curve, etc. More generally, n coordinatepairs (xi, yi) uniquely define a polynomial of degree n−1. The SPED 14processor generates the temporary polynomial equation, encodes thesecret (i.e., the SPED Master Key Encryption Key—MKEK or one of theApplication Key Encryption Keys) as the curve's y-intercept, and createsshares, each of which represent the coordinates of a point on thiscurve. When the shares from K entities are reconstituted to re-form thepolynomial curve, interpolation can compute the y-intercept thatrepresents the secret MKEK. It is also possible, using a well-knownoptimization of the Lagrange method, to recover a specific point withoutrecovering the entire polynomial.

This particular method was invented by Adi Shamir in 1979. Shamir'sscheme is provably secure, that means: in a (K,N) scheme one can provethat it makes no difference whether an attacker has K−1 valid shares athis disposal or none at all; as long as he has less than K shares, thereis no better option than guessing to find out the secret. Given any Kshares, the polynomial is uniquely determined and hence the secret MKEK,the “y” intercept, can be computed. However, given (K−1) or fewershares, the secret cannot be reconstituted.

Shrouding External Secrets

The external secrets cannot be used directly to reconstitute the secretMKEK. The shrouding operation discussed above provides additionalsecurity against attacks by ensuring that the secret shares do notremain in static storage within the system and are only reconstituted attheir time of use. The shrouding technique provides the additionaladvantage that a user's PIN or some other external input can easily bechanged by un-shrouding with the old value and re-shrouding it with thenew value, without have to replace the shared secret or re-deal all ofthe shares. Because of this approach, neither the share values nor theexternal secrets are ever stored on the SPED.

This scheme ensures that the shares cannot be recovered, even by asophisticated attacker who might “peel” the chip and attempt to analyzeit with an electron microscope or extremely small probes. The externalsecrets (e.g., PINs, authorization codes) are the only values knownoutside the SPED. Assuming that at least N−(K+1) of the external secretsremain secure, the MKEK is mathematically-provably secure, as the schemedoes not rely on the usual assumptions of “computational infeasibility”required for most cryptographic operations. So long as K shares areknown, the MKEK can be recovered, otherwise all of the data protected bythe MKEK will be irretrievably lost.

An external PIN, password, passphrase, or arbitrary string of bits ishashed using SHA-256, and that value “Exclusive OR'ed” (XOR) with itsassociated secret share value to provide the shrouded share value thatis maintained within the SPED. After the shrouding operation iscomplete, the (un-shrouded) secret shares are securely destroyed byoverwriting memory locations in which they were stored.

For this embodiment, K=5 and N=6, and the secret shares, in theirshrouded form, are stored within the cryptographic boundary of thecryptographic processing chip on the SPED 14 and never leave the device.The entities with shares include two classes—authorizing and enabling.At least one of the authorizing entities, the security officer PIN orthe user PIN, must be present in order to reconstitute the secret MKEK.Enabling shares are bound to at least: 1) the mediacontroller/microprocessor in the SPED 14, 2) the SPED itself throughidentification of its integral cryptographic processor chip, and 3) ahost-computing device. Optional shares may be created and stored withinthe SPED cryptographic processor for binding with other identifiedentities. Where a security officer is not involved, the user PIN and thesecurity officer PIN can be set to be equal. External PINs and/orpasswords uniquely associated with each of the entities arecryptographically associated with each of these shares as will bediscussed further below.

Block Diagram of the System and Its Constituent Parts

FIG. 2A is a block diagram of a system 200. The system 200 includes anHCD 201 and a SPED 202 that communicate via a communications interface203. The SPED may also optionally contain another communications portinterface (204) for connection to other types of peripheral devices 205,such as digital cameras, wireless or wire transceivers, memory devices,etc. The SPED 202 includes at least an integrated cryptographicprocessor IC chip set 202 a that enables cryptographic operations(examples of which are described in more detail below) to be performedon data that is stored within and “looped-back” to the HCD 201, datathat is transmitted from the HCD 201 to the SPED 202, data that istransmitted from the SPED 202 to the HCD 201, data that is transmittedfrom another peripheral device 205 through connection port 204 to theSPED, data that is transmitted from the SPED 202 to another peripheraldevice 205 through connection port 204. As explained in more detailbelow, the SPED 202 can obtain its mass memory capacity through integralconnection port 206 which interfaces to a mass memory storage module 207(e.g., a miniSD memory card). Alternatively, for more secureauthentication of users in the log on process, the SPED 202 can connect,as shown in FIG. 2C, through connection port 206 to a biometric module208 (e.g., a module including a fingerprint scanning device 209, aretinal scanning device, or a face print scanning device) with a securedirect entry scrolling thumbwheel or similar device 210, a displaywindow for status information 211, and an internal connector 212 forconnection to SPED 202 through connector 206.

Generally, the communications interface 203 can be embodied by any of avariety of communication interfaces, such as a wireless communications,USB, Firewire, Express Card, a serial such as an RS-232 interface, or aparallel interface. Each embodiment of the communications interface 203includes hardware present in each of the HCD 201 and SPED 202 thatoperates in accordance with a communications protocol (which can beembodied, for example, by software stored in a memory device and/orfirmware that is present in the HCD 201 and SPED 202) appropriate forthat type of communications interface, as known to those skilled in theart. Each embodiment of the communications interface 203 also includesmechanisms to enable physical engagement, as appropriate, between theHCD 201 and the SPED 202. Similar embodiments can exist forcommunications port 204 to connect peripheral modules 205 and the SPED202.

Generally, the cryptographic processor configuration 202 a can beconfigured to perform any electronic data cryptographic operation(herein, referred to simply as a “cryptographic operation”) including,for example, operations that provide one or more of the basiccryptographic functions, such as hashing, encryption/decryption, digitalsignature, key exchange, verification of data integrity, and userauthentication. Particular cryptographic operations that can beimplemented in the SPED 202 are described in more detail below.

The cryptographic processor configuration 202 a can be, for example, adedicated cryptographic processor in combination with an FPGA and an ARMmicroprocessor. Herein, “cryptographic processor” refers to an IC chipset configuration that performs cryptographic operations and thatincludes one or more mechanisms (such as, for example, use of a hardwarerandom number generator and/or protected memory) to provide security forthe content of those operations.

FIG. 2B is a perspective view of a physical implementation of the system200 of FIG. 2A, according to one embodiment of the invention. In FIG.2B, the SPED 202 of FIG. 2A is embodied as a flash card memory deviceform factor 215 that can be inserted into a corresponding USB socket 213formed in a laptop computer 214 that, in FIG. 3B, embodies the HCD 201of FIG. 2A.

In another embodiment, various pieces of metadata from the originalfile, including time and data information, file name, and other data,optionally including metadata specifically added by the user or attachedto the file through other mechanisms, including so-called Alternate DataStreams, may be included in final encrypted version of the file. Suchdata may be carried in the clear, i.e., unencrypted, or it may beencrypted using the same keys used to encrypt the data, or it may beencrypted in yet another key or keys, including the key(s) associatedwith a central repository or cataloguing service, or in some combinationof these keys. The function that performs this cataloging service willbe referred to as a Catalog Agent. The Catalog Agent may or may not bethe same entity as the Mandatory Recovery Agent described above.

Block Diagram of the System Showing Optional Memory Module and AdjunctAuthentication Module

FIG. 3A is a block diagram of an SPED 301, according to one embodiment,including an integral cryptographic processor chip set 302, a plug-inreplaceable/removable mass storage media 303 (e.g., miniSD memory card),and an optional authentication module 304 that consists of a biometricfingerprint scanner and a mechanism for securely entering analphanumeric PIN input device, such a thumbwheel, joystick, or touchscreen. It is possible, as explained in more detail below, to use themodular SPED 301 with the replaceable/removable mass memory storagemodule 303 without any connected biometric module 304 or externalperipheral device. The SPED 301 and memory module 303 are physicallyseparate devices that can be physically and electrically joined (asdescribed further below) to enable communication between the modules 301and 303.

Plan View of Physical Implementation

FIG. 3B is a plan view of a modular SPED 310 that represents a physicalimplementation, according to one embodiment, of the modular device 301of FIG. 3A. The SPED 310 includes a first module 311 and can attach to asecond module 325 through port connection 314 and can communicate withan attached peripheral 316 (e.g., wireless transceiver) through anadditional port connection 315. A connector 313 is formed at one end ofSPED 311. Opposite the connector 313 is a connector 314 for attaching aminiSD memory card 317 or other mass memory storage module or peripheral325 with a compatible connection interface for signaling and datatransfers.

For example, in one embodiment, an optional biometric fingerprintscanner 318 and alphanumeric user input device illustrated in FIG. 3 asa scrolling alphanumeric thumbwheel 319 with “push-to-enter”characteristics and display window 320 can be configured as a covering“sleeve” housing 321 to connect to the SPED through connections 314, forthe purposes of using a scanned fingerprint and secure user PIN entryfor securely authenticating the user to the SPED 310 and HCD 324. Themating connection of this biometric module 312 is constructed to have acompatible connection 322 within the recess of its housing tomechanically and electrically interface to the SPED module 311. The SPED311 can have a size and shape such that the SPED 311 can be directlyinserted into a USB connector socket 323 on the HCD 324, to enablecommunication between the HCD 324 and the SPED 310. Optionally, anotherexternal peripheral apparatus 316, e.g., a digital camera, a wirelesstransceiver, a memory media, may be directly attached or cabled to theport connection 315 for transferring data to or from the SPED 310.

Initiating Use of the System

FIG. 4 is a flow chart of a method 400 for initiating use of a system.The system that includes a SPED and a HCD can be implemented accordingto the method 400 so that policies can be accommodated for first timeinitialization of the system by a user or by a designated systemsecurity officer 402. Either designee proceeds through steps 403 or 414to load and install software on the HCD to display user procedures toinitialize, zeroize, change PIN, and view device properties of the SPED.The designated user inserts the SPED 404 into the connection socket ofthe HCD and the presence of the SPED is detected 405. The SPED isfurther configured to optionally recognize a particular recipient HCDthrough the setting of the Host Authorization Code in steps 406 or 407,and proceed to initialize the SPED 408 in preparation for the user orSSO authentication process as illustrated by steps 409 and 410 or 411,412, 413, and 415. In the case where the user is the designatedinstaller and initializer of the SPED, if successful authentication hasoccurred, the user may start the application 416. If the system securityofficer is the designated SPED installer and initializer, the SPED maybe delivered to the user by the security officer who initiates a log onprocess by which the user can enter their own PIN for processing throughsteps 417, 418 and 419. The user then proceeds to authenticate himselfto the device through steps 409 and 410 or 411, 412, 415, and ifsuccessful, starts the application in step 416.

It is to be understood that the method 400 shown in FIG. 4 is not theonly way to enable the embodiments of use of an SPED with a HCD asillustrated in FIG. 4. As can be readily appreciated by those skilled inthe art, such embodiments can be implemented using any of a variety ofother appropriate methods. Further, the installation of software andinitialization of a SPED can include embodiments not illustrated in FIG.4 as in the case of authentication default processes 413 and 420;likewise, such use may not include some of the embodiments illustratedin FIG. 4 because of specific security policies or regulations governingthe user's organization. The method 400 of FIG. 4 is shown merely to aidin the illustration of certain embodiments, and should not beinterpreted as restricting the manner in which an SPED can be used.

Description of the Host Computing Platform

FIG. 5 is a block diagram of an HCD 501 according to one embodiment,illustrating operation of the HCD 501 during a method such as the method400 of FIG. 4. The HCD 501 (e.g., as a desktop PC configuration)comprises a display device 502 (e.g., an LCD display, monitor), and userinput device 503 (e.g., a keyboard, touch screen, trackball, joystick orother appropriate device), referred to collectively hereinafter as userinterface device 503. The HCD 501 also comprises, mounted within ahousing 504, a processing device 505, a memory device 506, aninput/output (I/O) device 507 for enabling communication with the userinterface device 503, and an input/output (I/O) device 508 for enablingcommunication with the SPED. The devices 505, 506, 507, and 508 can eachbe implemented by conventional devices and can communicate with eachother via a conventional computer bus 509, as is well known andunderstood.

Description of the Separate Hardware and Software/Firmware Elements

FIG. 6 is a block diagram of system 600, according to one embodiment,comprising the separate hardware and software/firmware components thatare used in the cryptographic-processing, authentication, andauthorization processes such as the method 400 of FIG. 4. The HCD 601comprises resident applications software and drivers that interface withthe SPED 610 and cooperate to execute the secret sharing algorithm forcombining cryptographic shares from the user, the HCD 601, the SPED 610,and, optionally, an administrative security officer, to implement thesystem means for reconstituting the Master Key Encryption Key of themodule SPED 610 as will be described later. The user interface softwaremodule 602 is integrated into the operating system file system through abrowser shell and interacts with the user by providing the user withappropriate menus and messages. The SPED middleware 603 providesfunctionality that is used by the user interface to interact with themodular SPED 610. The SPED administrative tool software module 604provides a user interface for SPED administration that helps the user toinitialize, zeroize, change PIN, and view the device properties. Thefilter driver software module 605 is constructed as a file systemmini-filter driver that uses the operating system filter managercomponent. The USB function driver module 606 presents a MicrosoftWindows PCSC interface to the system and the host authorization servicemodule 607 is a service that runs in system space as part of the systemsmethods that protect the host authorization code and cooperates with theSPED 610 to support the execution of the shared secret algorithm. Inother operating systems, similar constructs could be used.

One embodiment of the SPED 610 includes a processor/controller device611, an FPGA 612, a cryptographic processing device 613, anattachable/replaceable memory device (e.g., miniSD, miniSDHC, ormicroSDHC memory card) 614, an input/output (I/O) device 615 forenabling communication with the host computing device 601, aninput/output (I/O) facility 616 for enabling communication with anoptional biometric fingerprint scanner and secure PIN entry device 620,and to communicate and interface with an optional peripheral device(e.g., a digital camera, an additional memory media, a wirelesstransceiver) 617. The components 611, 612, 613, 614, 615, 616, and 617can each be implemented by commercially made devices and can communicatewith each other via conventional computer busses as is well known andunderstood. The processor/controller 611 is a 32-bit ARM processor andis the main controller for all the secure mass storage operations andfor most interface data flows performed by the SPED module 610. It actsas the master state controller for the SPED module 610, and implementspublic key cryptographic and signing processing used during the fileencryption and decryption operations. It also implements a hashingoperation as part of providing the random numbers required for ephemeralkeys and other cryptographic values. The FPGA 612 provides high-speedexecution of AES-256 and SHA-384 algorithms (as well as other AES keysize and hash size alternatives) to supportencrypt-and-seal/decrypt-and-verify operations, as well as providing theinterface to the cryptographic processor 613 and the attachable massmemory (e.g., mini-SDHC memory card) storage device 614.

In one embodiment, the cryptographic processing device 613 isimplemented in a cryptographic controller that has been programmed forsuch processes. The secure operation of the SPED 610 uses this processorfor user authentication and for secure generation and storage of thestatic keys used during file encryption and decryption. It also providesan approved high-entropy random bit generator. In this embodiment, it isfabricated with special coating and electrical shield properties andzeroization schemes to protect the chip contents from sophisticatedelectronic “peeling” or scanning or invasive attacks to retrieve securecontents.

In another embodiment, an optional biometric authentication devicecomprises a fingerprint scanner and secure PIN entry 620 and serves toprovide, during the user log-on process, additional secure levels ofauthentication through biometric fingerprint scanning to match usertemplates captured and stored in the processor 621 memory of the 620during scanner training and initialization procedures. This physicalconfiguration embodiment fits as a sleeve over most of the SPED module610 and connects through an internal connector 625 that is within therecess of the module and interfaces with the SPED module 610. After thefingerprint scanner is used and the user fingerprint is verified, andsecure PIN entry is made through the human input device, and the user isauthenticated by the SPED module 610, and the log on process iscompleted and displayed to the user by the HCD 601, the sleeve may beremoved and the removable mass memory device 614 attached. The biometricauthentication device 620 includes an integrated control processor 621with on-chip RAM and flash memory, and a biometric fingerprint swipe orplaten sensor 622 used for capturing the fingerprint image that can beprocessed by the SPED module 610 for template matching and userauthentication. The biometric module 620 also comprises a scrollablethumbwheel or other form of human input device 623 for use in directsecure PIN entry by a user. When requested by the SPED module 610, thecontrol processor 621 will use this human input device 623 to collectthe PIN and send it directly to the SPED module 610 for userauthentication. A display 624 is used for displaying status messages andprompting the user for required inputs. The devices 621, 622, 623, and624 can each be implemented by conventional devices and can communicatewith each other via a conventional computer bus 626, as is well knownand understood. The HCD module 601, the SPED module 610, the biometricmodule 620, and the peripheral device module 617 are shown in simplifiedform in FIG. 6 to facilitate clarity in illustration of this embodiment,as described in more detail below and as understood by those skilled inthe art. The HCD module 601, the SPED module 610, the biometric module620, and the peripheral device module 617 can—and typically will—includeother devices not shown in FIG. 6.

Inter-Relationship of the Components

A significant advantage of the system according to the present inventioncomprising a SPED and a HCD is that the system comprises a set ofsequential procedures for system installation and initialization ofhardware and software subsystems to configure and integrate physical andlogical levels of access authorization for portable memory storageapparatus. The present invention accomplishes this by means of a K outof N split-knowledge technique that combines a mandatory minimum setof: 1) Host Authorization Code (HAC) information that can be specific toa HCD and enables a unique transformed external secret for each HCD, 2)the user's PIN, 3) an optional security officer's PIN, 4) SPED-specificinternal identification information, and 5) other unique identifierinformation that may be optionally required by an organization'ssecurity policies and procedures. The system can be implemented toemploy these individually created and independent authorizationparameters to reconstitute at least “K” shared data values whose totalcombination is required to reconstitute a Master Key Encryption Key(MKEK) that protects the private keys and the other criticalcryptographic parameters stored on the SPED against loss or all forms ofattacks.

The system that comprises a HCD and a SPED can, in general, beconfigured, initialized, and operated in one of two modes depending uponan organization's security policies and procedures: 1) requiring only asingle user PIN to install and initialize the system as in the case of asole proprietorship where the individual selected for the installationand initialization procedures can be the ultimate user of the system,and 2) requiring a second PIN assigned to an administrative systemsecurity officer (hereinafter referred to as SSO), as in a government orcommercial institution protecting valuable intellectual property orvital national interests. The system can enable a system securityofficer or other designated security administrator, according to thepolicies and procedures of an organization, to be the designated personto physically initialize the SPED with the HCD in order to limit theaccess only to those users, SPEDs, and HCD host computers that have“need to know” access permissions as defined by such policies andprocedures. The system can be implemented so that under such a securitypolicy, first the system security officer can create the HAC for eachdesignated HCD, then create an SSO PIN and initialize the SPED, and thencan distribute an SPED to the user for the creation of their PIN as inFIG. 4, Method 400, steps 402, 403, and 414.

As discussed further in this Description, there can be delineationbetween the required authorized actions of a user and anadministrator/security officer. Unless otherwise specified, the generalterm user will apply to both.

Referring to FIG. 6, the system that includes a SPED and a HCD can beimplemented so that first time use of the system begins when the userloads (either through media (e.g., CD-ROM, the SPED memory download) ornetwork interconnection) and installs mass storage software 602, 603,605, 607, into the HCD 601 which includes its own device drivers 605 forthe SPED replaceable/removable storage module 614. This software alsoincludes operational and user interfaces 602 for the SPEDreplaceable/removable storage module 614. When prompted by theappropriate software module, a user of the system connects the modularSPED 610 device to the HCD. Such connection can occur in any manner thatenables the SPED to communicate with the HCD. Frequently, this willoccur as a result of a physical connection of the modular device to thehost-computing device. For example, the SPED can be implemented as a USBflash memory token (e.g., a form factor conforming to a USB connectionas established by the appropriate standard), or alternately by anExpressCard form factor, that is inserted into a corresponding socketformed in the HCD. Alternatively, the SPED can be implemented in ahousing from which a connection cord extends, a plug of the cord beinginserted into a mating receptacle formed in the HCD. However, suchphysical connection need not necessarily occur; the SPED can also beconnected to the HCD by any type of wireless communication, e.g.Bluetooth or infrared, for which the HCD contains an appropriateinterface.

The system that includes a SPED and a HCD can be implemented so that forthe first time use of the system, a user can also load and installadministrative tools software 604 on the HCD 601 that provides userinterfaces and procedures to initialize, zeroize, change PIN and viewdevice properties on the SPED 610 and operate the SPED 610 and HCD 601systems. In the case of a physical connection, a user inserts the SPED610 into the connection socket of the HCD 601. Once connection betweenthe SPED 610 and the HCD 601 is made, the HCD 601 detects the presenceof the modular device. Such detection of the presence of a peripheraldevice is typically enabled as a standard embodiment of the softwareinstalled into the HCD.

Support for Software-Only and/or Hybrid Decryption and RecoveryMechanisms

All of the hashing, symmetric key encryption/decryption, and public keyoperations (key establishment and digital signatures) may be performedwithin the security perimeter of the trusted hardware security device.However, in order to satisfy potential cost constraints for the RecoveryAgent capability, another embodiment may comprise a hybrid means wherebya decrypt-only capability could be provided, wherein only the public keyoperations are implemented within a hardware device, and the hashingand/or symmetric key operations are carried out in software on the hostcomputing device. Yet another embodiment may consist of a purelysoftware implementation of the Recovery Agent decryption capability.

Mathematically Protected Enhanced Authentication Mechanisms and Indicia

In another embodiment, the authentication and authorization methods usedwithin the SPED are sufficiently extensible as to deal with otherenhanced authentication devices, methods, and functions, in such amanner as not to necessitate the storing of such enhanced authenticationparameters (e.g., biometric indicia, user proximity detection code,permitted operational location information, etc.) for later comparisonin such a manner that such parameters could be extracted and used, undereven national laboratory conditions.

Embodiment Using a Host Authorization Code

In a further embodiment, an organization security officer/administrator,or an individual user loads a set of software modules into thehost-computing device from a CD-ROM, from a read-only portion of theSPED itself, or from other forms of software distribution media,including wireless communications. The administrator/user determines ifthe SPED is to function only on one or more designated host computingdevices, or with any and all host computing devices. In the case ofassigning the SPED to only work with designated host computing devices,the SPED executes, prior to initialization, a series of programs toestablish one or more named or default “Host Authorization Codes (“HAC”)which can be unique to each host computing device or can be shared amongan enclave or Community of Interest of users. In an information systemconfiguration involving multiple Originators, Recipients and hostcomputing devices, an administrator can, personally or by delegation toa trusted representative, cause the same HAC to be set on each HCD orcan set multiple HACs on HCDs if the host computing devices are to beshared by different user enclaves or Communities of Interest. In thecase of setting up the SPED to work with any host computing device, adefault HAC is created and the initialization program creates anindividual PIN and generates new sets of cryptographic signature andencryption keys. In the case of security policies of centralizedorganizations, the administrator can generate a system security officerPIN and each user PIN number to complete the initialization process.Although the HAC used within an enclave may be the same for all the hostprocessors within the enclave, a “diversified” version of the HAC may becreated by hashing or encrypting the stored HAC value together with theserial number of SPED device, prior to loading the diversified HAC ontothe SPED, in order to ensure that a “wire-sniffing” attack could onlycompromise the particular diversified value of the HAC used for thatparticular SPED, and not all such devices.

In another embodiment, the integrated SPED processor mediates thecommunications between the host computing device (HCD) and the SPEDitself, as a result of user interface enabled instructions provided bythe host computing device, to allow various options for userauthentication and log on, device initialization, optional setting ofthe host authorization code (HAC), and control of the processing andflow of the encrypted/decrypted data. One security mode encrypts datafrom the HCD and stores it directly in the SPED memory media for storageor communication with another device. In an alternative mode, data fromthe HCD is encrypted and returned directly in a “loop-back” mode ofoperation, without being stored for application usage by the SPEDmemory, and, in the reverse situation, data from the HCD is sent to theSPED for decryption and then returned. It is important to note that HCDdata encrypted by the SPED can only be accessed and decrypted by a userwho has the PIN and the SPED device, and an authorized computer, if ahost authorization code process has been established.

In a further embodiment, the SPED is activated by the user through theinput of a PIN to execute the log on process and gain access to thefacilities of the SPED. The PIN is established during an initializationprocess, which can be executed by an individual user acting as asecurity administrator. Alternatively, in an organization with acentralized administrator and set of tiered or multi-level securitypolicies, the system security officer can initialize any SPEDs. The usermay be allowed to change his or her own PIN/password, or that abilitymay be blocked by a policy option.

Another benefit of a system that includes a SPED 610 and a HCD 601 isthat the system can be implemented so that an optional HostAuthorization Code (HAC) can also be set so that the SPED 610 willfunction only with HCDs 601 set up with the appropriate HAC (i.e. thesame HAC that has been set on the SPED 610). This embodiment of thepresent invention can provide a unique fourth level of authentication,(in addition to the physical possession of the device, the knowledge ofa PIN, and the biological sensing of some user's physicalcharacteristic, e.g., a fingerprint), namely identification andauthorization of a particular HCD(s) 601 in order for an authorized userto logon and access the information on the SPED 610.

Depending upon the organization's policies, a user or SSO can log on tothe HCD and set the Host Authorization Code (HAC) by creating a long,statistically unlikely to guess or discover (in excess of 100alphanumeric characters; for highest security, the present embodimentpermits up to 255 alphanumeric characters) random or pseudo-random code,which can be generated by blind fingering actions on a keyboard, or bycreation of a pseudorandom or random code by the SPED cryptographicprocessor 613, or by an application program that runs on the HCD 601,and whose results can be copied and transferred as the HAC input to theHAC creation program. This input HAC alphanumeric string can be putthrough a transform (e.g. a one-way hash function) before beingmaintained on the HCD 601 or being set on the SPED 610. This HAC, in itstransformed form if this has been done, is stored in the HCD 601registry in an encrypted form that is specific to the computer (HCD) onwhich the SPED 610 will be authorized to operate. This is accomplishedby using a unique property of the HCD, such as an internal serial numberof the bios chip, processor chip, or other secure readable or calculablemethod of identification installed by the manufacturer for unique HCDidentification and licensing. Access to this encrypted HAC value in theregistry is further protected against extraction or copying, byauthorization services SPED authorization service 607 softwareprocedures allowing read only access only to designated administrators.Users that do not belong to this group cannot have any accesspermissions to the registry key or value.

The HAC will also be sent to the SPED 610 to set up this value as theauthorization code used for recovering its corresponding share to beused in the K of N derivation of the MKEK. Before setting the HAC valuein the SPED 610 it can also be transformed yet again in order todiversify it so that it is unique to the SPED on which it is set, sothat a compromise of a HAC for a particular SPED would not compromisethe HAC for all SPEDs used with a common HAC through a common enclave ordomain, for example. This requires using something unique to the SPED610 (e.g. the SPED serial number) and combining it with the HAC toperform the transform before sending it to the SPED (e.g. append theSPED serial number to the HAC and then cryptographically hash thecombined value). Of course, this same process will be used when theshared secret is first generated and the shares created.

The particular manner in which the HAC shared secret can be set isdependent upon the initial entry of a pseudo-random alphanumeric stringand the binding of the creation of the secret to a specific identity ofthe HCD 601. Using this process the same HAC can be set on more than oneHCD 601 allowing a particular SPED 610 (an SPED initialized with thisparticular HAC) to be used on multiple HCDs. However, if the appropriateHAC has not been set on a particular HCD 601 the SPED 610 in question(the SPED initialized with this HAC) will not be able to beauthenticated, therefore blocking its use on that HCD 601.

In addition, when saving the HAC on a particular HCD 601, the HAC canoptionally be assigned a common name associated with that particular HACvalue. In this way, multiple HACs can be set for a single HCD 601, eachonly valid for the specific SPEDs that have been initialized with thisparticular named HAC. Using this feature, a given host can supportmultiple levels of security classifications, each with it own communityof interest as defined by a common named HAC.

To illustrate this mode of operation, the system that includes a SPEDand a HCD can be implemented to permit alternative creation of HACs forremotely located HCDs, on which the proper SPED mass storage andadministrative tools software have been loaded. For example, in analternate embodiment of the present invention as illustrated in FIG. 1,multiple remotely located host computing devices are connected to anetwork 22 in a client-server configuration which also comprises aserver 21 An Originator 11 can create a host authorization code on theirspecific host computing device 13 and secure portable encryption device14, and share this HAC with other Recipients or users 17 in the sameCommunity of Interest without requiring individual user interaction bythe Originator's SPED 14 with each host computing device, bycommunicating the Originator's created host authorization code by acryptographically secure mutually authenticated client-server channelconnection 22 to a system server 21.

Distribution of the Originator created host authorization code to thehost computing devices of the designated members 17 of the enclave ordomain transmits the shared HAC through a cryptographically-secure,mutually-authenticated client-server channel connection 22. Since theexternal host authorization code is transformed by the SPED using aunique identifier from each HCD, the HAC secret can only be correctlyreverse transformed by the same HCD and combined with the other sharedsecrets to reconstitute the MKEK. In this manner, multiple HACs may becreated to be distributed to combinations of host computing deviceaccording to security policies and the designation of Communities ofInterest.

In one further embodiment of the present invention, a given SPED 610 canonly support a single HAC and therefore a single, optionally namedclassification level. At the time of SPED 610 initialization, the nameof the HAC 601 specified for operating with a given SPED 610 is carriedas a public object in the SPED 610 cryptographic processor 613 and isaccessed by the HCD middleware 603 after insertion of the SPED, and thematching HAC in the HCD 610 list of HACs will be loaded into the SPED615 in order to enable a user to log on from the particularauthenticated HCD.

User Authentication after the HAC has been Set

A further embodiment of a system is that once the HAC has been set, theuser continues with the process of initialization of the SPED 610.Before use of the secure data processing applications of the SPED 610for the first time, the SPED 610 must be initialized to generate keysand set the user Personal Identification Number (PIN). Preferably, aminimum length of at least seven alphanumeric characters for the PIN isentered via keyboard input. Optionally, the SPED device can beconfigured to require an even longer PIN, and/or imposed variouscomplexity requirements such as the number or upper and lower casecharacters, numbers, and/or special characters. The system according tothe present invention can require PIN entry either from a keyboard inputassociated with the HCD 601, or from a secure PIN entry device 623integrated with a biometric (e.g. fingerprint) scanner 622 as dictatedby security policies for user authentication.

The SPED can identify, through the HCD microprocessor 611 operatingsystem software, the presence of a secure PIN entry/biometric verifierdevice 620. In one embodiment, in the event that biometricidentification fails, then PIN entry is blocked. If biometricauthentication is successful, and incorrect PINs are used to try toaccess the SPED 610, either as a result of forgetting the PIN or anattack, the time between successive tries can be doubled each time tofurther increase the difficulty of attack, particularly if the device isleft unattended and attached to a host computer. After ten tries, acounter in the SPED cryptographic processor can signal the logic in theSPED to become blocked to prevent a further brute force attack to gainaccess. The threshold count can send a logic signal to cryptographicprocessor 613 and encryption keys can be deleted and the PINs completelyreset.

A SPED can be implemented so that when the PIN entry process is completeand approved, the initialization process continues with the generationof static keys for file encryption, of public/private signature keypairs with private keys stored in cryptographic processor 613, of keyencryption keys for wrapping and protecting file encryption keys, andgeneration of an AES-256 Master Key Encryption Key for encryptedprotection of the entire contents of all keys and critical cryptographicparameters stored within the SPED cryptographic processor 613. Referenceis made to U.S. Pat. No. 6,088,802, “Peripheral Device With IntegratedSecurity Functionality,” and U.S. Pat. No. 6,003,135, “Modular SecurityDevice,” both of which are incorporated by reference in their entirety.

When the Master Key Encryption Key (or an individual Application keyEncryption Key) is generated during initialization, “N” secret sharesassociated with that key are created by the cryptographic processor 613.This embodiment of the secret sharing algorithm incorporated by theinvention, namely that a minimum set of K out of N shares must becombined to reconstitute the Master Key Encryption Key (or the specificApplication Key Encryption Key for the application that is beingselected) at log on, and that the HAC, user PIN, and SPED 610 data mustbe within the K set, makes the SPED 610 information storage contentsprovably secure against access and cryptographic attacks unless allthese codes are available. Without the proper HAC, it is mathematicallyimpossible for anyone to be able to log on to the device and access ordecrypt the data contents, even if the user PIN is known.

When PIN creation is complete, the SPED is ready for log on and allcryptographic processing operations.

Detection and Use of the SPED and Any Mass Memory or Peripheral Device

The SPED may be equipped with a non-volatile memory storage device, suchas a miniSD or microSD memory card, available in various sizes up tomultiple gigabytes in a very compact form-factor. The memory can behard-wired and non-removable, but preferably is removable andreplaceable via a built-in memory chip socket.

In another embodiment the SPED takes the form of the SPYRUS HydraPrivacy Card® Series II (Hydra PC™) using either the USB interface orthe ExpressCard™ interface that is intended to be plugged into a socketwithin the host computer device housing. This embodiment is of the typeof form factor generally used in “flash memory” drive products. Analternate embodiment would include the ExpressCard™ form factor, usingan adapter cable with appropriate voltage-reducing circuitry to connectthe ExpressCard™ to a USB connector on the host device. Other alternateembodiments of the SPED can be of the form of a handheld multimediacommunications device such as a cell phone, smartphone, MP3 player,video player wherein the host computing device can be a local userdesktop or laptop computer, or a remote media distribution facilityinterconnected by wireline or wireless communications over the Internet.

When the user PIN is created, connection between the SPED 610 and theHCD 601 is made, and the user logs on to the SPED through one of thePIN/biometric methods previously described, the host computing device610 detects and identifies the presence of the SPED in the manner ofplug-and-play protocols as is known in the state of the art. The SPEDdetects the presence and identity of the associated non-volatile massmemory storage module 614 and any peripheral device 617 that isconnected to the secondary I/O connection port 616. Such detection ofthe presence of an attached peripheral device 617 is typically enabledas a standard embodiment of the operating system software of the SPEDprocessor 611.

Typically, once the presence of an attached peripheral device 617 isdetected by the operating system software of the SPED 610, the operatingsystem software (or companion software program) also identifies the typeof the peripheral device (e.g., digital camera, wireless transceiver,disk memory module). This can be accomplished, for example, by astandard software device driver (hereinafter, “SPED driver”) forperipheral devices 617 of the type that use the SPED secondary I/Oconnection port 616. In FIG. 6, the SPED driver is stored in the RAMmemory 611 a of the SPED processor 611. It is to be understood that theexamples given above are merely illustrative, not exhaustive, of theways in which a peripheral device 617 can be used. Many morepossibilities exist.

Though, as shown in FIG. 6, the SPED includes cryptographic processingfunctionality, and also provides connection to peripheral devicefunctionality 617, the system 600 can be operated so that only thecryptographic processing functionality is used.

The SPED device driver and HCD interface, administrative, and middlewaresoftware can have been previously installed to the RAM memory of thehost computing device via an appropriate interface (such as a CD-ROMdrive or network connection), as previously discussed for first useinstallation and initialization, at the time when the user firstinitiated interaction between the host computing device and the SPED.Additionally, when a SPED device is used with a host computing devicewhich utilizes operating system software that supports the featureinformally referred to as plug and play, the SPED related software canbe stored in non-volatile storage memory 614 of the SPED or, asavailable, in the SPED 611 a microprocessor memory configuration. Thus,when the SPED is connected for the first time to a particular hostcomputing device, the host computing device can automatically providethe user with the opportunity to instruct the host computing device tocause the SPED interface, middleware and device driver software to betransferred from the SPED memory to the host computing device.

Modes of Operational Use

FIG. 7 is a flow chart of a method 700, according to an embodiment, forusing an SPED. Once user authentication has been acknowledged andapproved, the user can begin using the SPED (in particular, thecryptographic processing functionality of the SPED), as shown by steps701, 702, 703, 704, and 705 of the method 700. Such use can be enabledby software programs that are cooperatively executed by the hostcomputing device and the SPED.

It is to be understood that the method 700 shown in FIG. 7 is not theonly way to enable the embodiments of use of an SPED that areillustrated in FIG. 7; as can be readily appreciated by those skilled inthe art, such embodiments can be implemented using any of a variety ofother appropriate methods. Further, the use of a SPED can includeembodiments not illustrated in FIG. 7; likewise, such use may notinclude some of the embodiments illustrated in FIG. 7. The method 700 ofFIG. 7 is shown merely to aid in the illustration of certainembodiments, and should not be interpreted as restricting the manner inwhich an SPED, can be used.

A SPED can, in general, be operated in one of four modes: 1) a mode inwhich the cryptographic processing functionality is used on data createdby the HCD and is stored in the SPED mass memory module 614 for physicaltransport or subsequent electronic communication, 2) a mode in which thecryptographic processing functionality is used on data created by theHCD and is looped back to the HCD for storage in an HCD integral orattached memory storage module or for communication to a server orremote storage device, 3) a mode in which the cryptographic processingfunctionality is used on data communicated by the attached peripheraldevice 617 and is stored in the SPED mass memory module 614 for physicaltransport or subsequent electronic communication, and 4) a mode in whichthe cryptographic processing functionality is used on data communicatedby the attached peripheral device 617 and is looped back to the attachedperipheral device 617 for storage in the peripheral device integral orattached memory storage module.

Upon receipt of an acceptable user authentication input, the SPEDsignals the host computing device to present a user interface thatenables the user to effect desired control of the SPED, and, inparticular, to use the SPED to perform cryptographic operations, asdescribed below. The user interface for enabling a user to operate theSPED can be implemented in any of a variety of well-known ways (e.g., asa graphical user interface) using methods and apparatus that are wellknown to those skilled in the art. Generally, the user interface enablesthe user to perform any functionality that is provided by the SPED asdescribed in more detail elsewhere herein.

As indicated above, a SPED can be operated in any of four modes. Once anacceptable user authentication has been approved, the peripheral devicedriver can enable the user to select one of the four modes, as shown instep 706 of the method 700. The HCD user interface software and theunderlying middleware, drivers, applications, and interface softwareenables the user to input all desired or required instructions regardingthe cryptographic data processing operations to be performed for aparticular “transaction” (e.g., encryption of a file from the HCD forstorage in the mass memory module 614, the transmission of encrypteddata by an attached peripheral communications device, or a loop back ofdata encrypted for storage in the HCD) as shown by steps 710,711, and712 of the method 700. For example, again referring to FIG. 6, the userinterface software module 602 can enable the user to select on whichdata cryptographic operations are to be performed, specify theapplication of particular cryptographic operation to that data, andspecify parameters or other information required for a particularcryptographic operation.

For example, if the cryptographic functionality is embodied asencryption of files and folders from the HCD 601 for storage on the massmemory 614 of the SPED 610, the file or folder icon is highlighted andselected on the HCD displayed graphical user interface, and, for exampleon a Microsoft Windows system, a drop-down menu lists “Encrypt to SPED”as a prompt for clicking on the item to execute the action and implementthe data transfer through modules 605, 606, and 615, and to effectcryptographic processing actions via the appropriate cryptographicresources available from the appropriate SPED cryptographic processingmodules 611, 612, and 613. If more than one SPED is inserted into theHCD when files or folders are encrypted, the HCD software 603 and 606will prompt the user to select the destination SPED. The file or foldername stays unchanged and a new file extension is added to indicate thatthe file is encrypted.

Once the user has provided instructions in steps 706 and 707 or 710 or713 or 714, the particular cryptographic processing transaction isexecuted, as shown by step 708 or 711 or 714 or 717 of the method 700.After execution of the cryptographic processing transaction, the data istransferred to the appropriate destination via step 709 or 712 or 715 or718. Eventually, use of the SPED ends, as shown by step 719 of themethod 700.

Use of the SPED for General Cryptographic Processing, Including PKIFunctions

The cryptographic processing functionality of a SPED can be configuredto perform any cryptographic operation, as well as other, relatedmathematical operations. A configuration of the cryptographic processingfunctionality that enables a particular cryptographic or mathematicaloperation can be produced, for example, by using appropriate existingcryptographic software, application-specific hardware, or combination ofthe two, as known by those skilled in the art of producing cryptographicdevices.

In particular, the SPED can be configured such that the functionality ofthe Crypto Processor (613) serves in a manner similar to a conventionalsmart card or USB token for carrying out a wide variety of cryptographicand PKI functions, including both legacy (RSA, DSA, triple-DES, SHA-1)and advanced (EC Diffie-Hellman, ECMQV, ECDSA, AES, and SHA-2)algorithms in combination with HCD application and/or operating systemsoftware. Examples of such processing include hardware-based public keyoperations carried out within the SPED, with symmetric key and hashingfunctions carried out in software on the HCD, for applications such assmart card logon, IPSEC link encryption, SSL/TLS encryption and mutualauthentication to web servers, secure and authenticated e-mail (S/MIME),pre-boot authentication for Full Disk Encryption solutions, WiFi linkencryption, and other similar cryptographic protocols and purposes knownto those skilled in the art.

Following is a description of exemplary cryptographic and mathematicaloperations that can be implemented as part of the cryptographicprocessing functionality of a SPED. These cryptographic and mathematicaloperations are well known and can readily be implemented in a SPED by aperson of skill in the art of cryptography.

For example, a SPED can implement one or more cryptographic key exchangeoperations. Any key exchange operation can be implemented, such as, forexample, the ECDH, the ECMQV, the RSA, and the X9.42 (ANSI BankingStandard) key exchange algorithms.

A SPED can also implement one or more hash operations. Any hashoperation can be implemented, such as, for example, theSHA-224/256/384/512, SHA-1, and the Message Digest 5 (MD5) algorithms.

A SPED can also implement one or more digital signature operations. Anydigital signature operation can be implemented, such as, for example,the ECDSA Digital Signature Algorithm, and the RSA Signature (1024,2048) algorithms.

A SPED can also implement one or more key wrapping operations for bothsymmetric and asymmetric keys. A key wrapping operation can ensure thatplaintext keys are not accessible external to the portable device. Anykey wrapping operation can be implemented.

A SPED can also implement one or more symmetric encryption operations.Any symmetric encryption operation can be implemented, such as, forexample, the AES-128/192/256 with ECB, CBC, CTR, and key wrap modes, andthe DES (including 3DES, EDE3, CBC and ECB).

A SPED can also implement one or more asymmetric (public key) encryptionoperations. While asymmetric encryption operations underlie the keyexchange operations described above, asymmetric key operations can alsobe used independently in a SPED for bulk encryption. Any asymmetricencryption operation can be implemented, such as, for example, the RSA,Diffie-Hellman, and Elliptic Curve Diffie-Hellman algorithms, andvarious variants thereof.

A SPED can also implement one or more exponentiation operations, whichare required in many cryptographic operations. Any exponentiationoperation can be implemented. Since exponentiation requires asignificant amount of processing time relative to other mathematicaloperations, it can be desirable to implement an exponentiation operationin dedicated hardware. In one embodiment of a SPED, the cryptographicprocessing functionality of the portable device includes a fullexponentiator implemented in hardware.

A SPED can also implement one or more random number generations, whichare required in many cryptographic operations. Since high quality randomnumber generation is required for robust, strong key generation andother critical cryptographic functions, and requires a significantamount of processing time relative to other mathematical operations, itis desirable to implement random number generation with approvedalgorithms in dedicated hardware. Cryptographic processing functionalityof the portable device includes a full random number generatorimplemented in hardware.

Provision for a Multiplicity of Mandatory and Optional Recipients of theEncrypted Data

In another principle embodiment of the present invention, the files orrecords to be encrypted, digitally signed, and/or sealed may include amultiplicity of file header information sufficient to allow multipleRecipients (optionally including the Originator) to be able to decryptand verify the information that has been so protected, whether that datahas been recorded on the storage medium contained within the SecurePortable Encryption device itself, on an integral or ancillaryencryption device connected to the host computing device, or some otherencryption device that is logically accessible to the Host ComputerDevice or the Secure Portable Encryption device.

A means of designating a number (zero or more) of Mandatory RecoveryAgents or Recipients of the secured information that cannot be bypassedby the normal originator may be provided on behalf of the institutionunder the control of the System Administrator or System Security Officeron a per HCD basis; together with some other number (zero or more)Optional Recipients specified by the originator, that are required orallowed to be able to decrypt the encrypted information. This set ofMandatory and Optional Recipients is not necessarily limited to a singleenclave as defined by a single common named or default HostAuthorization Code (HAC), but instead can confine communications betweenand among a fixed set of users operating in different enclaves, whilepreventing users from accessing or decrypting the information outside oftheir own authorized enclave, even if they possess the secure portableencryption device and know the user PIN. This invention dynamicallydefines and configures the authorized population and tiers of users,portable encryption devices, and host computing devices that are allowedto communicate through the flexibility of support of multiple HostAuthorization Codes by each host-computing device.

Use of Public Keys and Credentials

In another embodiment of the present invention, the credential(s) of theRecipient(s) may be provided to the Secure Portable Encryption device(SPED) in the form of a raw public key, for example suitable for use inthe EC Diffie-Hellman or ECMQV key establishment scheme, through sometrusted out of band process. Alternatively, the Recipient's credentialsmay be embedded in a conventional X.509 digital certificate, which hasbeen digitally signed by a trusted Certification Authority or chain ofCertification Authorities acceptable to the Originator.

In another embodiment, the user's credentials in the form of one or moreX.509 certificates, including a certificate and certificate chain thathas been signed using the legacy public key algorithms (e.g., RSA orDSA) and legacy hash functions (MD5 or SHA-1), together with the user'sSPED ECC encryption and digital signature public keys, may be boundtogether in either a proprietary format or an X.509 attributecertificate, and signed using the user's/SPED high-strength ECC digitalsignature key. Such an approach would allow the user's legacycredentials to be validated using the existing (typically RSA-based)certificate infrastructure and revocation checking mechanisms, whilestill making use of the much higher-strength ECC keys for long-termtransactions.

Data Recovery Through Strong But Brittle Cryptography

In another embodiment of the present invention, the various Mandatory orOptional Recipients may be differentiated and selected by the guaranteedlongevity of the secrecy of the private keys held by those Recipients,e.g., an Historical Recovery Agent. It is envisioned that the privatekeys associated with such a Historical Recovery Agent would be splitinto independent shares using a secret-sharing algorithm, and thoseshares entrusted to a large number of universities, public libraries,museums, government archives, religious organizations, and other stableand long-lived institutions, such that many but not necessarily all ofthose institutions working in concert, e.g., perhaps 70 out of 100,would be able to reconstitute the private key. The public key associatedwith the Historical Recovery Agent could be included within an X.509 orother form of public key certificate, with the expiry period beingplainly indicated in the certificate itself. Those institutions couldthen gather in a conclave perhaps once per decade, reconstitute theprivate key that was destined to expire on that date, and publish it tothe world. As a result, documents that had been securely encrypted forthe last 10, 20, 50, or even 100 years would instantly become readilyaccessible to future generations.

Containment of Encrypted Data to Authorized Users within a NamedCommunity-of-Interest by Means of a Network Access Code

Another embodiment of the means for securely protecting decryption is toutilize a Network Access Code (“NAC”) as part of a shrouding operationon file encryption keys. In this embodiment, means are provided tooptionally restrict the decryption of encrypted information flowing toor from (a) the HCD via the SPED, and (b) one or more other (remote)authorized user(s); unless both the Originator of the encryptedcommunication and all of the Recipients of said encrypted communicationshare a common pre-shared NAC or key, which is associated with thecreation of a named Community of Interest of authorized members in sucha way that if both the Originator and a particular Recipient do not bothknow the Network Authorization Code the Recipient will not be able todecrypt the information, even if the Originator has knowledge of andtrusts the Recipient's public key.

This Network Authorization Code may be stored on the user's SPED, oralternatively on the HCD or some external device or server, or evensplit between and among the SPED, the HCD, and some user-providedinformation using a secret-sharing algorithm (for example, as describedabove), and may be used as part of an overall data containmentenforcement mechanism to ensure that information is not communicated,either physically or logically (e.g., via a communications network) tounauthorized users, even on a cross-domain basis. The NAC can be used toenforce data containment to within a group or domain of authorizedusers, by requiring the Originator and all of the various Recipientsknow or share a common NAC for that domain.

Means are further provided to securely generate, distribute, store andaccess, use, and recover the NAC throughout the Community of Interest.Various means, including encrypting the NAC in the public key of theauthorized user's SPED device, can be used to distribute the NACsecurely, such that it can be stored on the SPED device itself, on thehost processor that is used, or on some external device such as aserver, so that it can be retrieved and used. Optionally, similar meanscan be used to distribute the named NAC for a given Community ofInterest to one or more Community-Of-Interest Recovery Agents, so thatit can be reconstituted in the event of the loss or destruction of theSPED or even the death or disability of the user.

As will be understood by those skilled in the art, the management ofpossession of this NAC could take a multiplicity of forms, ranging froma simple out-of band communication of the password or passphrase used togenerate the NAC; up to a complex, world-wide network of Community ofInterest Registrars and Recovery Agents responsible for authenticatingthe identities, clearance levels, and bona fides with respect tomembership in the Community of Interest.

The NAC is exclusive-ORed (XORed) or otherwise combined (e.g., by theuse of encryption or some other invertable transform) with the FileEncryption Key used to encrypt the file or message, to create what maybe called a Shrouded File Encryption Key (SFEK). This SFEK can then beencrypted in the normal manner with a Key Encrypting Key that is derivedfrom the EC Diffie-Hellman or other key exchange mechanism through astandard key derivation process as described in the literature. As willbe appreciated by those skilled in the art, this process makes itimpossible to decrypt the File Encryption Key, and therefore the fileitself, unless the EC Diffie-Hellman key exchange operation takes placesuccessfully, and the NAC is known.

Details of the Cryptographic Key Exchange Mechanisms

FIG. 8 is a flow diagram that illustrates one embodiment of how keymanagement is performed within the SPED 811 when a NAC is used. Forevery file that is to be encrypted, a new ephemeral public/private ECCkey is generated for the Originator 800. The public ephemeral key thatis generated at the same time (not shown) is saved for inclusion in theFile Header 817 of the Encrypted File 813. The SPED receives theRecipient's static public key 801 from an external source, which may bean X.509 public key certificate or similar construct 804. The EllipticCurve Diffie-Hellman operation 802 is carried out in the conventionalmanner, by multiplying the Originator's private ephemeral key times theRecipient's static public key in the ECC field. The output of thatfunction is a shared secret, conventionally called Z, that is passed toa Key Derivation Function (KDF) 803 such as the Concatenation KeyDerivation Function defined within SP 800-56A. Other supplementarypublic and/or private information 804 may be passed in to the KDF aswell, in order to bind the key that is generated to the identity of theparties. The output of the KDF is a Key Encrypting Key (KEK) 804.

Independent of the EC D-H key agreement, a random generated symmetricFile Encryption Key (FEK) 806 is generated for the file, along with arandomly generated Initialization Vector (IV) 810. In addition, the NAC805 is retrieved from secure storage within the SPED, and both the NACand the FEK are passed to the shrouding operation 807, which may simplyexclusive-OR the two values together, or alternatively might encrypt theFEK using the NAC as a key.

In either case, the output of that operation is a Shrouded KeyEncryption Key, which is input as data to the AES Key Wrap operation 808and wrapped with the Key Encryption Key (KEK) 804 that was previouslycomputed by the KDF.

The output of the AES Key Wrap operation is a Wrapped Key Blob 809,which is then written to the File Header 817 of the encrypted file 813.Also included in the File Header is the Originator's ephemeral publickey (not shown) that was generated at the same time as, and correspondsto, the Originator's ephemeral private key 800, as well as theInitialization Vector (IV) 810.

The symmetric File Encryption Key 806 together with the InitializationVector (810) is then used to encrypt the plaintext data 816 using theconventional Cipher Block Chaining mode of operation, or alternatively amode such as Galois Counter Mode, to create the final Encrypted File813.

The operation of this process during the decryption step is almostidentical, except that the role of the Originator's ephemeral privatekey and the Recipient's public key are reversed. In other words, theRecipient uses his or her static private key instead of the Originator'sprivate ephemeral key 800, and uses the ephemeral public key obtainedfrom the File Header instead of the Recipient's public key 801.Otherwise, the operation proceeds exactly as for the encryption step,except that the File Encryption step 811 is replaced by a decryptionoperation.

Mitigation of Quantum Computing Attacks

An additional benefit of the NAC would apply in the event quantumcomputing ever becomes practical. Although it is hypothesized that someday it might be possible to use quantum computing as a tool to “break”an RSA, ECC, or other public key algorithm that might be used to encryptthe Shrouded File Encryption Key, breaking that algorithm would do theattacker no good at all without the knowledge of the NetworkAuthorization Code. Assuming the NAC is XORed with the File EncryptionKey, and that the NAC itself is distributed by a secure, out-of-bandprocess, i.e., it is not itself encrypted in a public key system, thenthere are no mathematical or cryptographic processes that could beattacked using quantum computing other than a brute force exhaustivesearch attack against a 256-bit key.

Separation of Function between Trusted Third Party Recovery Agents

In yet another embodiment, means are provided for surviving the loss,theft, destruction, or eventual failure or obsolescence of a SPED byrecovering, at a trusted third-party File Recovery Agent, the fileencryption keys used to encrypt a multiplicity of files and thensecurely re-encrypting the individual file encryption keys associatedwith the data (but not the data itself) using a new encryption key orset of keys installed in a newer or replacement SPED, all the whileguaranteeing that the Recovery Agent cannot access or decrypt thecontents of the file without knowing the NAC that was used when the filewas originally encrypted.

In yet another embodiment, means are provided for surviving the loss,theft, destruction, or eventual failure or obsolescence of a SPED byrecovering the Network Access Code or NAC, though the use of aCommunity-of-Interest Recovery Agent (CRA), that would receive and storethe encrypted NAC used within a Community of Interest, and could upon anauthenticated demand, export that NAC to an authorized user's SPEDdevice, but without ever having access to the private key or keys of anyof the authorized users SPED devices, and hence without the ability todecrypt the data itself.

Generating, Distributing, Storing, and Using the Network AuthorizationCode

It will be understood by those skilled in the art that there are amultiplicity of means methods that could be used to securely generate,distribute, store, and make use of the Network Access Code.

In one instantiation, which might be well-suited for casual use byfriends and family or social networks, the NAC could be entered by theOriginator during the encryption process (and by the Recipient(s) duringany decryption), in the form of a passphrase that would be entered viathe keyboard attached to the HCD, with the passphrase being passed tothe SPED by the host software and hashed within the SPED to form the NACbefore it is used.

The NAC can be given a unique name, and centrally managed by a Communityof Interest manager or authority. For example, a community of interestof automobile parts manufacturers might be established by Chrysler, sothat those vendors could communicate with Chrysler, but Ford would notbe able to originate or decrypt messages to that COI. Likewise, Fordcould set up their own COI, and Chrysler would not be able toparticipate, but those vendors that sold to both Chrysler and Ford wouldbe able to communicate with both, but separately.

The NAC would be randomly generated using a random number generator inan SPED, and then encrypted in the ECC public key of the authorizeduser, using a conventional EC Diffie-Hellman and Key Derivation Functionto encrypt the wrapped NAC. Once created, the named wrapped NAC could besent to an authorized user in any convenient manner, including e-mail,FTP, etc. Upon receipt by a user, the named NAC could be stored on theSPED token itself or it could be stored on the HCD for retrieval asneeded. The NAC would be decrypted by the SPED prior to use.

An additional embodiment recognizes that in order to recover a file orother information at some distant point in time, it will be necessary torecover the NAC as well as being able to decrypt the Shrouded FileEncryption Key. Because databases of keys, NACs and other suchinformation might become disassociated from the message or otherwiserendered inaccessible, it is highly desirable that the encrypted NACinformation be carried in the encrypted file or message itself. For thatreason, preferably the NAC will be encrypted in the public key of theauthorized user, and in the public key or keys of one or more Communityof Interest Recovery Agents (CRA). In this embodiment, the NAC would beencrypted only once per user, but the encrypted form would include thewrapped version of the NAC, encrypted one or more times for the variousCRAs. Because the wrapped value of the named, encrypted NAC would neverchange from the time it is created, it can simply be included in everymessage as a opaque blob. The Originator of the message or file would beable to decrypt the NAC, if necessary, using the private key of theSPED, and any authorized CRA would be able to decrypt that NAC, but thevarious Recipients would not be able to decrypt it, because it was notencrypted using their keys. In order to decrypt the message, theRecipient would have to have received their own copy of the NAC,encrypted in their own public key, in order to decrypt and apply the NACand subsequently decrypt the message.

Assured Protection Against Tampering Via an Independent Guard Processor

In an optional embodiment, means are provided through which anindependent Guard Processor computer or mechanism can verify that theentire contents of any encrypted file or other form of data wereproperly encrypted and have not been tampered with or accidentallymodified since that time. The means makes use of a secure hash functionthat is computed by the SPED contemporaneously or simultaneously withthe encryption operation, with the resulting hash function beingdigitally signed by the Originator's digital signature key and thesignature being embedded in the file metadata or trailer along with thepublic signature key to be used for verification. In this embodiment,the validity of the Originator's public key can be established through atrusted out-of-band mechanism, e.g., an X.509 certificate that is signedby a trusted Certification Authority, or one or more public key orauthorized Originators that are securely installed in the GuardProcessor under the System Security officer's control. Through thismeans and apparatus, the authenticity of the ciphertext can beestablished without any necessity for the Guard Processor to require oreven possess the ability to decrypt the information.

In some environments, the Recipient may not have received out-of-bandconfirmation of the Originator's public signature key, which might allowan attacker to substitute a bogus public key in the file metadata(trailer). In order to prevent this from occurring without detection,preferably the SPED includes the Originator's public signature key (asobtained from the file metadata) within the Key Derivation Function thatis used by both the Originator and a Recipient to derive the KeyEncrypting Key used to encrypt the File Encryption Key. If theOriginator's public key were modified in the file, the Recipient wouldnot be able to rederive the key necessary to decrypt the file, and theprocess would fail.

In another embodiment of the present invention, the Guard Processorfunction may be implemented in software on a user's HCD, and used toblock or filter all information that has not been properly encryptedfrom being written to (or alternately read from) another mass encryptiondevice or other media, unless it has been properly encrypted, in orderto prevent the leakage of sensitive plaintext information.

ADDITIONAL SPED EMBODIMENTS

Numerous variations and additions to the SPED can be made, withoutdeparting from the scope of the invention.

Robust File-Based End-To-End Error Correction Means and Mechanism

Optionally, various forms of Forward Error Correction (FEC) may beincluded within the encoded structure of the encrypted file itself,logically after the file has been encrypted and hashed as part of thedigital sealing mechanism. In order to minimize the latency involved,FEC may be applied while the file is being encrypted and the ciphertexthashed, all in a single pass. During the decryption process, anyexisting errors will be corrected prior to hashing the encrypted fileand perform the decryption operation. As will be understood by thoseskilled in the art, various forms of Forward Error Correction can beapplied, including but not limited to simple Reed-Solomon (255,233)code, wherein 233 bytes of data plus 32 bytes of parity information areencoded into a 255 byte block. Such a code can correct up to 16 shortbursts of error. More complex coding techniques, such asCross-Interleaved Reed-Solomon Coding (CIRC) technique used in CompactDisks can completely correct error bursts of up to 4000 bits. The use ofsuch techniques can enable the complete recovery of encrypted messagesthat might otherwise be rendered completely unintelligible due to aslittle as a single bit error.

Provision of an Adjunct Enhanced Authentication Device

The SPED can be connected to an optional Enhanced Authentication Device(“EAD”), which contains a biometric fingerprint scanner that comparesthe fingerprint input data to fingerprint templates previouslyregistered and stored within the SPED. This apparatus provides anadditional authentication factor of “Who you are” to positively identifythe user as the legitimate unique user, or one of a set of authorizedusers who has previously registered their fingerprints on the SPED tostrongly and securely bind their identity as an authorized user toaccess the operations on the SPED.

In a further embodiment, the optional EAD takes the form of a coveringsleeve and includes a secure PIN entry mechanism to allow the PIN orpassword to be entered directly into the SPED without the need tocommunicate the PIN over an external or unprotected communicationschannel.

User Authentication Combined With Proximity Detection

In another embodiment, the proximity of the authorized user to the SPEDmay be confirmed by means of an RFID tag, Bluetooth device, or otherlimited near-field or wireless communications mechanism that is normallyworn on or attached to the user's person, and may be “paired” to eitherthe SPED or the EAD, so that if the user leaves the immediate area ofthe SPED that condition will be sensed, and the user required to log onagain before taking further actions with the SPED. Other sensors andmore exotic applications could likewise be supported, including livefinger determination, blood-alcohol content, two-man rule conditions,etc.

Extensions of the Authentication Mechanism to Fuzzy Multivariate Factors

In some cases, the normal mode of operation would be for the SPED to beused within limited geographical locus, e.g., within a corporate campus,and use outside of that locus would be prevented. Rather than storingthe authorized locus and comparing it to the current position, with therisk that it might be possible to extract the authorized coordinates anddetermine how to spoof the device, in another embodiment thisgeographical locus can be managed by having the EAD determine thecurrent geographical position. (e.g., from a GPS or Loran system, or bytriangulation form cell phone towers or similar means), and then apply acoordinate transformation to effectively round both the X and Ycoordinates to define a more limited precision locus. This “fuzzy” orlimited-precision locus can then be used as one of the authenticationand authorization parameters that are entered into the secret-sharingauthentication algorithm at the time the SPED is initialized and thekeys are generated, just as the user PIN, Host Authorization Code, an/orother authorization parameters are entered.

In yet another embodiment, the extension of the authentication andauthorization parameters from what is effectively a precise,one-dimensional Host Authorization Code to a fuzzy two-dimensionalgeographic position locus can be extended to three or more dimensions,including altitude, time or day, or other multivariate coordinates. Forexample, many pattern-matching algorithms used in biometric applicationscan be viewed as a multi-dimensional variation around a known point,which is determined by the biometric template or indicia. In thisembodiment, the template would be entered into the secret-sharingauthentication and authorization algorithm, and the allowable degree ofdeviation from that template would be implemented through the coordinatetransformation and truncation or rounding algorithm, so that it wouldnot be necessary to store the template itself for comparison where itcould possibly be compromised. Those skilled in the art will recognizethat it is desirable to ensure that a sufficient amount of entropy beprovided during this process, so as to make it computationallyinfeasible to guess or exhaustively search for parameters that wouldsatisfy the enhanced authentication/authorization criteria. Thisobjective can be accomplished by combining a multiplicity of suchparameters into a single split-knowledge share. If necessary, a randomseed, serial number, or other variable that is unique to a particularenhanced authentication device may be hashed or otherwise combined withthe relevant parameters in order to make it more difficult to mount anexhaustive search.

Extensions to Multiple Cryptographic or Application Partitions

In another further embodiment, the SPED is constructed with amultiplicity of logical cryptographic or application partitions, inorder to permit sharing a single SPED among or between multiple users,as in a branch office, or engineering design or finance group, whereeach user can have access to their own unique private keys. In othercases, e.g., within a military or surveillance operation, multiple usersof the same device can be authorized, each with their own PIN orpassword and optional biometric identifier, but the various users canall share access to a common set of decryption keys, for purposes ofsurvivability. In that scenario, each user might or might not haveunique digital signature keys.

In a similar embodiment, the SPED can be constructed with a multiplicityof logical cryptographic or application partitions, so that certain lesssensitive applications can be performed without requiring the HostAuthorization Code or other authorization parameters to be storedexternally, while still requiring the HAC for the more sensitiveapplications. One such application would be the use of the SPED forpre-boot authentication of a Full Disk Encryption software or hardwareapplication, where there is no secure location in which to store a HACuntil the operating system has completed the boot process, and hence itwould be desirable to use independent HACs for maximum security. Anothersuch application would be the use of the SPED to access MultipleIndependent Security Levels when dealing with a classified environment.One set of user PIN/password, HAC, and biometrics might authorize accessto a host computer at the Unclassified level, another set at the SECRETlevel, and yet another set at the TOP SECRET level. If a particular useror SPED is not authorized to access the higher level securityclassifications, the HAC for that classified enclave security levelwould not be loaded onto the SPED by the Security Officer.

In yet another embodiment, a multiplicity of independent SPEDs, eitherwith or without the capability of interfacing to a removable memorydevice, may be aggregated into a single physical device containingmultiple SPED devices, all capable of functioning independently atdifferent security levels, and connected to the HCD by a multi-pin plugand socket arrangement containing e.g., as many as 16 differentconnecting pins, as may be required to support the I/O requirements.Each SPED could then be dedicated to distinct security levels, e.g.,Unclassified, CONFIDENTIAL, SECRET, and TOP SECRET, providing completeelectrical as well as application and cryptographic separation betweenlevels.

Interfaces to Other Media

In a further embodiment, the SPED may take the form of a digital mediarecorder/receiver or an “ipod” type device, which includes a largecapacity micro disc hard drive or internal mass memory chip, andconnects to the host computing device through a miniUSB or adapter cableconnection, or wireless connection, depending upon the native interfaceof this SPED. A touch screen display may enable a keyboard to bepresented to the user to provide a means for entering a PIN numberdirectly into the SPED without transporting the PIN from an unprotectedexternal device and communications channel.

In a further embodiment, a SPED apparatus is constructed and enabled toalso perform one or more cryptographic operations on data that has beentransmitted to the SPED by a remote wireless device by inclusion of awireless transceiver, or input to the SPED by a person through akeyboard, or input to the SPED by another peripheral device (e.g.,digital camera, disk storage module) through an additional secondaryphysical connector and communications port.

In another embodiment, the host computing device may be a programmableproduct such as laptop, desktop or UltraMobile PCs, a PDA cell phone, adigital audio or video recorder, a photographic camera or recorder, withan embedded microprocessor that supports applications software,peripheral device interfaces, and graphical user interfaces, andoperates on digital data in any format (e.g., encoded alphanumeric,video, audio, photographic).

Use of the SPED for Biometric Authentication

The SPED 610 and an associated peripheral device driver may beimplemented so that it is possible to use the functionality of the SPED,even without accessing any cryptographic processing functions of theSPED. Using the SPED in this way can be useful, for example, when thetargeted functionality (referring to FIG. 6) is embodied as the securePIN entry/biometric authentication device 620, previously described,that is used to perform user authentication. In particular, if device620 is to be used as the mechanism to enter the user PIN in FIG. 7 step704, operation in this mode may be necessary (depending on thecapabilities of the biometric device) to enable such use of thebiometric device.

The biometric authentication device is defined herein as any device thatis adapted to receive input data regarding a physical characteristic ofa person based upon a physical interaction of the person with thedevice. Biometric devices that can be used in a peripheral device caninclude, for example, a fingerprint-scanning device, a retinal scanningdevice, or a face print scanning device. A biometric device includes asensor for sensing the physical characteristic, and an analog-to-digitalconverter to transform the analog data representing the sensedcharacteristic into digital data. For example, a fingerprint-scanningdevice includes a sensor upon which a person can place or swipe afinger, the sensor sensing the fingerprint of the finger, the content ofthe sensed fingerprint being converted into digital data by the device.Similarly, a retinal scanning device includes a sensor that can beplaced proximate to a person's eye, the sensor sensing characteristicsof the eye such as blood vessel pattern or iris pattern, the devicetranslating the content of the sensed characteristics into digital data.The construction and operation of biometric devices in general, as wellas those identified particularly above, is well understood by thoseskilled in that art, so that, together with an understanding of therequired communication capability between the biometric sensor and thecontrol processor 620, a biometric device for use with the invention canbe easily operated. Fingerprint scanning devices and retinal and faceprint scanning devices that can readily be modified for use with theinvention, i.e., to communicate with the control processor 620, areknown to those skilled in that art.

In a further embodiment, the secure PIN/biometric device 620 contains ahuman input device 623 for scrolling through alphanumeric charactersthat are sequentially displayed on display screen 624. As each desiredcharacter appears on the display screen 624, a selection is made and thecharacter is locked. After the correct sequence of characters isentered, they can be entered as the PIN, in one embodiment, by scrollingthe thumbwheel to an “enter” position and pressing inward. The securePIN entry is transferred to the SPED cryptographic processingconfiguration modules 611, 612, and 613 via control processor 621 andI/O modules 625 and 616 to determine authentication approval by matchingthe stored PIN data.

If biometric approval is also required as an authentication procedure,the biometric scanner 622 may be used to scan the user's biometricfingerprint data into the SPED control processor 621 according to theparticular instructions and settings of the scanner parameters. If acorrect match is made after comparing the biometric data to anappropriate library of biometric data representing a predetermined groupof people (e.g., authorized users) stored within the processor 621, theresultant user authentication approval is sent from the controlprocessor 621 via I/O modules 625 and 616 to the SPED microprocessor611. (Of course, in this case, user authentication is used as part ofthe step 714). Again, eventually, use of the SPED device ends (step719).

Embodiments Utilizing Wireless Communications

A further system embodiment 922 is illustrated in FIG. 9. In thisconfiguration 922, the HCD 915 is similar to that presented in FIG. 5and can take the form of some portable form factor physicalconfiguration for a PC, a PDA phone, a smartphone or other such similardevices. The HCD 915 is comprised of a microprocessor 912, an internalmemory 913, a computer bus 911 for interconnection of the internalcomponents of the HCD 915, a data input mechanism for user inputillustrated herein as a keyboard 914 which is connected to the HCD 915through a USB input/output module and connector 910. Alternatively, awireless connection can be used to interconnect a data input device 914to the HCD 915. As previously described in FIG. 6, the host computingdevice executes the software modules 605, 606, 601, 602, and 607necessary to interface with the secure portable encryption device andthe secure portable encryption device mass memory. Referring to FIG. 9,the HCD 915 includes a wireless input/output module and connector 909for communications to other devices using WLAN IEEE 802.11, Bluetooth,or such other wireless communications methods as may be adopted forindustry use by handheld digital computer and communicating devices andhost computing devices. Wireless communications is enabled by HCD 915internal or external antenna 908.

Referring to FIG. 9, the secure portable encryption device 900 may beimplemented in a form of digital data media recorder/receiver 900containing an integrated or removable mass memory disc or mass memorychip module 901. This secure portable encryption device 900 alsocontains a control microprocessor 903, internal RAM memory 904, aninternal communications bus 902, and input/output module and connector906 which includes a wireless capability and is connected to internal orexternal antenna 907 through which communications is effected. Wirelesscommunications can utilize a method such as Bluetooth, WLAN IEEE 802.11protocols, or other methods adopted by industry providers. Wirelesscommunications can be implemented using one of the industry securitymethods (e.g., WAP2 IEEE 802.11i, Bluetooth mutual authentication methodfor encryption key generation) for establishing a mutually authenticatedephemeral session encryption key between the HCD 915 and the SPED 900 inorder to secure communications of critical security parameters that areexchanged between the HCD 915 and the SPED 900.

This configuration 922 may execute all security operations as have beenpreviously described for occurring within the secure portable encryptiondevice 900 for protection of the SPED memory 901 data by means ofsoftware stored in a partition 905 of the internal memory, oralternatively and not illustrated, in a separate EEROM memory connectedto computer bus 902. The control microprocessor 903 processes all memoryapplications, initialization applications, generates the ephemeralpolynomial curve from which the “N” shared secrets and Master KeyEncryption Key (MKEK) are created, and performs the security processingoperations necessary to cryptographically associate each shared secretwith an external secret, (e.g., the user PIN, the security officer PIN,the unique identifier for the HCD, the identification of the specificsecure portable security device), and all other cryptographic algorithmsand related memory storage applications as are required and store suchvalues in non-volatile permanent memory of the SPED.

The system secret sharing means implemented by the SPED 900 controlmicroprocessor 903 and security processing programs stored in memory 905do not require static storage of the external secrets and the MKEK andthus provides the advantage of avoiding these vulnerabilities which aresubject to brute force and other attacks. Installation andinitialization software modules (not illustrated) as previouslydiscussed may also be stored within the SPED 900 to be directlydownloaded to a HCD 915 without the necessity of using a separatedigital media, e.g., CD-ROM.

As previously discussed, user authentication can be implemented by PINinput through the data entry device 914 for the HCD 915, or, foradditional levels of secure authentication, through a separate biometricand secure PIN entry device 916, configured in this embodiment in a USBflash memory portable form factor. Other form factors may also beimplemented. The biometric authentication device 916 is connected to thehost computing device through a USB connection 921 which mates with theUSB input/output and connector module 910 on the HCD 915. The biometricauthentication device 916 may be comprised of a biometric sensordepicted in FIG. 9 as a fingerprint sensor 917, a scrolling thumbwheel918 for selection and input of the alphanumeric characters to composethe PIN, a display 920 to provide status to the user, and an internalcontrol microprocessor 919 for execution of all operations.

The choice of algorithms and techniques for encryption/decryption,digital hashing, digital signing, and other related operationsassociated with these operations is not meant to be limited by thisdisclosure. Such choices are expected to change over time, due to newstandards being set by governments and institutions and standards-makingbodies for acceptance by all communities, and this invention is notlimited, in implementation, to any one set of such cryptographicalgorithms and techniques.

It is to be understood that the various configurations and embodimentsof the system, methods, and apparatus which have been described aremerely illustrative, not limitative, of an application of theprinciples. It will be apparent to one skilled in the art that numerousmodifications may be made to the system configurations, methods, andapparatus described herein without departing from the scope of theclaims set out below.

1. A portable encryption device with logon access controlled by anencryption key, comprising: an enclosure for the device providing aportable form factor, and a cryptographic processor within the enclosurefor reconstituting the encryption key from a plurality of secretsgenerated by a secret sharing algorithm.
 2. The device of claim 1, wherethe secret sharing algorithm comprises a K out of N secret sharingmechanism.
 3. The device of claim 2, where the K out of N secret sharingmechanism comprises Shamir's Secret-Sharing Algorithm.
 4. The device ofclaim 2, where the K out of N secret sharing mechanism comprisesLagrange interpolation.
 5. The device of claim 1, where one or more ofthe generated secrets have been shrouded with one or more externalsecrets using an invertible transform, such that any one of the externalsecrets may be changed without recreation or re-dealing of all of theplurality of generated secrets.
 6. The device of claim 5, where theinvertible transform is XOR.
 7. The device of claim 5, where one or moreof the external secrets comprise a user's PIN.
 8. The device of claim2.6, where the PIN is a supervisory user's PIN.
 9. The device of claim5, where the external secrets comprise a plurality of user's PINs, andthe transform is invertible with less than all of the plurality ofuser's PINs.
 10. The device of claim 5, where one or more of theexternal secrets comprise a firmware hash.
 11. The device of claim 5,where one or more of the external secrets comprise a host authorizationcode associated with one or more specific host computing devices,binding the portable encryption device to such one or more hostcomputing devices.
 12. The device of claim 5, where one or more of theexternal secrets is generated by a proximity detection mechanism. 13.The device of claim 5, where one or more of the external secrets is afunction of multivariate parameters.
 14. The device of claim 13, wherethe multivariate parameters are chosen from the group consisting of ageographic-locus and biometric input.
 15. The device of claim 1, furthercomprising means for communicating the external secrets over a securechannel with a secondary device.
 16. The device of claim 15, where thesecondary device is a connected host computing device.
 17. The device ofclaim 15, where the secondary device is a remote device.
 18. The deviceof claim 1, where the encryption key is a master key encryption key. 19.The device of claim 1, where the encryption key is an application keyencryption key.
 20. The device of claim 1, further comprising means forinterfacing with a user authentication device.
 21. The device of claim20, where the authentication device comprises a secure PIN entrymechanism.
 22. The device of claim 20, where the authentication devicecomprises a secure biometric input.
 23. The device of claim 1, furthercomprising removable memory configured for data storage.
 24. The deviceof claim 1, further comprising a data communication module.
 25. Thedevice of claim 1, where the cryptographic processor is a microprocessorprogrammed to execute cryptographic functions.
 26. The device of claim1, further comprising a second cryptographic processor within theenclosure.
 27. A method for controlling logon access on a portableencryption device having a portable form factor and a cryptographicprocessor, comprising: generating a plurality of secrets by a secretsharing algorithm, configuring the cryptographic processor toreconstitute an encryption key from the plurality of generated secrets,and determining logon access as a function of the reconstitutedencryption key.
 28. The method of claim 27, where the secret sharingalgorithm comprises a K out of N secret sharing mechanism.
 29. Themethod of claim 28, where the K out of N secret sharing mechanismcomprises Shamir's Secret-Sharing Algorithm.
 30. The method of claim 28,where the K out of N secret sharing mechanism comprises Lagrangeinterpolation.
 31. The method of claim 27, further comprising shroudingone or more of the generated secrets with one or more external secretsusing an invertible transform, such that any one of the external secretsmay be changed without regeneration or re-dealing of all of theplurality of secrets.
 32. The method of claim 31, where the invertibletransform is XOR.
 33. The method of claim 31, where one or more of theexternal secrets comprise a user's PIN.
 34. The method of claim 33,where the PIN is a supervisory user's PIN.
 35. The method of claim 31,where the external secrets comprise a plurality of user's PINs, and thetransform is invertible with less than all of the plurality of user'sPINs.
 36. The method of claim 31, where one or more of the externalsecrets comprise a firmware hash.
 37. The method of claim 31, where oneor more of the external secrets comprise a host authorization codeassociated with one or more specific host computing device, binding theportable encryption method to such one or more host computing devices.38. The method of claim 31, where one or more of the external secrets isgenerated by a proximity detection mechanism.
 39. The method of claim31, where one or more of the external secrets is a function ofmultivariate parameters.
 40. The method of claim 39, where themultivariate parameters are chosen from the group consisting of ageographic-locus and biometric input.
 41. The method of claim 27,further comprising communicating the external secrets over a securechannel to a secondary device.
 42. The method of claim 41, where thesecondary device is a host computing device.
 43. The method of claim 41,where the secondary device is a remote device.
 44. The method of claim27, where the encryption key is a master key encryption key.
 45. Themethod of claim 27, where the encryption key is an application keyencryption key.
 46. The method of claim 27, further comprising receivinginput from a user authentication device.
 47. The method of claim 46,where the input is received over a secure channel.
 48. The method ofclaim 46, where the input comprises secure biometric data.
 49. Aportable encryption device with file decryption controlled by a fileencryption key, comprising: an enclosure for the device providing aportable form factor, and a cryptographic processor within the enclosurefor reconstituting the file encryption key from a version of the fileencryption key which has been shrouded with a network authorizationcode.
 50. A method for controlling file decryption with a portableencryption device having a portable form factor and a cryptographicprocessor, comprising: generating a network authorization code,distributing the network authorization code to a community of interestthrough an out-of-band distribution mechanism, shrouding a fileencryption key with the network authorization code using an invertibletransform, receiving the network authorization code from a user, causingthe cryptographic processor to reconstitute the file encryption key fromthe received network authorization code, and determining file decryptionas a function of the reconstituted file encryption key.
 51. The methodof claim 50, further comprising decrypting an encrypted file as afunction of the reconstituted file encryption key.
 52. The method ofclaim 50, where the invertible transform is XOR.
 53. The method of claim50, where the invertible transform is resistant to quantum computingattacks.
 54. The method of claim 50, further comprising encrypting thenetwork authorization code and distributing the code to a recoveryagent.
 55. A method for file encryption of a plaintext file, comprisingthe steps of: hashing the plaintext file to produce a plaintext hash,compressing the plaintext file, encrypting the compressed plaintext fileto create ciphertext, hashing the ciphertext to produce a ciphertexthash, hashing the plaintext hash and the ciphertext hash to produce aresult hash, and sealing the ciphertext together with the result hash,to produce the encrypted file.
 56. The method of claim 55, furthercomprising steps for communicating the encrypted file tooriginator-selected optional recipients.
 57. The method of claim 55,further comprising steps for an enforced mandatory recovery agent. 58.The method of claim 55, further comprising steps for breaking theencryption of the encrypted file at a pre-determined date.
 59. Themethod of claim 55, the sealing step further comprising embeddingforward error correction within the encrypted file.
 60. The method ofclaim 55, the plaintext file having metadata, further comprising thestep of separately encrypting the metadata, and the sealing stepcomprising sealing the ciphertext together with the result hash and theencrypted metadata.
 61. The method of claim 60, further comprising stepsfor an independent key exchange mechanism to permit decrypting themetadata by catalog agent.
 62. The method of claim 55, furthercomprising use of a portable encryption device having a portable formfactor and an on-board cryptographic processor to perform one or more ofthe steps.
 63. A portable encryption device for encryption of aplaintext file, comprising an enclosure for the device providing aportable form factor, and a cryptographic processor within the enclosureconfigured to perform the steps of claim 55.